HWA.hax0r.news #13 HTML/Text Version
Cubesoft, our new home. RETURN.
Our REDIRECTOR
Canc0n99 411 be there or be square
- This issue may cause strangeness in certain browsers
read in TEXT mode to see why.
HWA is sponsored by Cubesoft communications www.csoft.net
a proud CANADIAN company.
[ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
==========================================================================
= <=-[ ]-="" HWA.HAX0R.NEWS> =
==========================================================================
[=HWA'99=] Number 13 Volume 1 1999 April 1st 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:! ]
==========================================================================
On writing 'too technical' in an English assignment ....
she said "put it in laymen's terms"
i was thinking "you mean lamers' terms??" - *G*
010010 0101010101
01010101 0101010101010
010101 010101
010101 01010101
010101 01010101
010101 010101010
0010101010 01010100101010
0101010101 0101010101010
Note that some stuff may not display correctly as I did not fully convert
all the text contained in this file to html, it is recommended you read
this file in standard text mode...
4445494c0494C554E4C554E
=------------------------------------------------------------------------=
=------------------------------------------------------------------------=
Synopsis
---------
The purpose of this newsletter is to 'digest' current events of interest
that affect the online underground and netizens in general. This includes
coverage of general security issues, hacks, exploits, underground news
and anything else I think is worthy of a look see. (remember i'm doing
this for me, not you, the fact some people happen to get a kick/use
out of it is of secondary importance).
This list is NOT meant as a replacement for, nor to compete with, the
likes of publications such as CuD or PHRACK or with news sites such as
AntiOnline, the Hacker News Network (HNN) or mailing lists such as
BUGTRAQ or ISN nor could any other 'digest' of this type do so.
It *is* intended however, to compliment such material and provide a
reference to those who follow the culture by keeping tabs on as many
sources as possible and providing links to further info, its a labour
of love and will be continued for as long as I feel like it, i'm not
motivated by dollars or the illusion of fame, did you ever notice how
the most famous/infamous hackers are the ones that get caught? there's
a lot to be said for remaining just outside the circle...
@HWA
=-----------------------------------------------------------------------=
Welcome to HWA.hax0r.news ... #13
=-----------------------------------------------------------------------=
*******************************************************************
*** /join #HWA.hax0r.news on EFnet the key is `zwen' ***
*** ***
*** please join to discuss or impart news on techno/phac scene ***
*** stuff or just to hang out ... someone is usually around 24/7***
*** ***
*** Note that the channel isn't there to entertain you its for ***
*** you to talk to us and impart news, if you're looking for fun***
*** then do NOT join our channel try #wierdwigs or something... ***
*** we're not #chatzone or #hack ***
*** ***
*******************************************************************
=-------------------------------------------------------------------------=
Issue #13 Artificial intelligence is no match for natural stupidity.
=--------------------------------------------------------------------------=
[ INDEX ]
=--------------------------------------------------------------------------=
Key Content
=--------------------------------------------------------------------------=
00.0 .. COPYRIGHTS ......................................................
00.1 .. CONTACT INFORMATION & SNAIL MAIL DROP ETC .......................
00.2 .. SOURCES .........................................................
00.3 .. THIS IS WHO WE ARE ..............................................
00.4 .. WHAT'S IN A NAME? why `HWA.hax0r.news'?..........................
00.5 .. THE HWA_FAQ V1.0 ................................................
01.0 .. GREETS ..........................................................
01.1 .. Last minute stuff, rumours, newsbytes ...........................
01.2 .. Mailbag .........................................................
02.0 .. From the Editor..................................................
03.0 .. Why Business Fears Distributed Attacks...........................
04.0 .. April Popular Mechanics article: Hackers and Crackers............
05.0 .. What IS frame spoofing etc anyways?..............................
06.0 .. What should I fear from Java and ActiveX?........................
07.0 .. Some cool geek code (leetbuzz.c) to roll your led's from root....
08.0 .. Building a packet sniffer from the ground up Part I..............
09.0 .. CIAC Security advisory on HP-UX ftp,hpterm.......................
10.0 .. Sendmail DoS on versions up to latest 8.9.3......................
11.0 .. Xylan Omniswitch 'features' (DoS)................................
12.0 .. xfs (font server for X) bug, exploitability warning..............
12.1 .. xfsx.sh - Very simple shell script exploit code for the recently
discovered xfs security hole. By ArchAng3| of Death, Midgard
Security Team. .................................................
13.0 .. Bug allows remote systems to read local files remotely in MSIE5
14.0 .. Possible root/user level compromise in SCO TermVision............
15.0 .. Linux INSMOD exploit/vulnerability...............................
16.0 .. Webramp DoSability...............................................
17.0 .. HP Security bulletins (March 31).................................
18.0 .. VENGINE polymorphic mutation engine for the Melissa virus w/code.
18.1 .. [ISN] Virus camp split over melissa virus........................
18.2 .. [ISN] The Anarchic Lure of Virus Writing ........................
18.3 .. A shadowy bunch...Philly Inquirer................................
18.4 .. National Post "Hang Hackers like Coin Clippers"..................
18.5 .. Second victim, erh suspect fingered on Melissa virus in Europe...
19.0 .. Various vulnerabilities;.........................................
1. Overflow in CAC.Washington.EDU ipop3d 4.xx...................
2. Overflow in pine 4.xx (Linux)................................
3. Lockfile vunerability in pine 4.xx (Linux)...................
4. Lockfile vunerability in ipop3d 4.xx.........................
5. Linux 2.x IPC vunerability...................................
6. Linux 2.x mmap vunerability..................................
7. Midnight Commander 4.x bugs (x2).............................
20.0 .. AOLwatch news....................................................
21.0 .. AntiOnline and hacker attacks....................................
22.0 .. NATO fights Serbs online.........................................
23.0 .. Chicago man sues employer over having weak voicemail security....
24.0 .. Mitnick speaks in a rare Q and A, (Forbes).......................
25.0 .. Australian stock exchange to carry out threat on Y2K slackers....
26.0 .. Hack your Palm V to add eight mb of ram!.........................
27.0 .. MDT software mentioned in last issue warrants arrests............
28.0 .. Hot on the trail of infamous hacker/cracker Zyklon, BUSTED!......
28.1 .. Rebuttal by Fluxx;..............................................
29.0 .. Atlanta based ISS looks to hire hackers from OZ..................
30.0 .. More on hacktivism from the Boston Globe.........................
31.0 .. Some nasty WinGate 3.0 DoS's, password fun and other probs.......
32.0 .. Sekure team releases problems found with ISS-scanner (rewt sploit!)
33.0 .. FileGuard crack, security vulnerabilities........................
34.0 .. Linux system administration mini-howto by Pestilence ............
35.0 .. Guide to using NMAP by Lamont Granquist .........................
36.0 .. Digital Unix 4.0 has potential root compromise in /var perms.....
37.0 .. Running Procmail
- Picture postcards
- CD's 3.5" disks, Zip disks, 5.25" or 8" floppies, Qic40/80/100-250
tapes with hack/security related archives, logs, irc logs etc on em.
- audio or video cassettes of yourself/others etc of interesting phone
fun or social engineering examples or transcripts thereof.
If you still can't think of anything you're probably not that interesting
a person after all so don't worry about it
Our current email:
Submissions/zine gossip.....: hwa@press.usmc.net
Private email to editor.....: cruciphux@dok.org
Distribution/Website........: sas72@usa.net
@HWA
00.2 Sources ***
~~~~~~~~~~~
Sources can be some, all, or none of the following (by no means complete
nor listed in any degree of importance) Unless otherwise noted, like msgs
from lists or news from other sites, articles and information is compiled
and or sourced by Cruciphux no copyright claimed.
HiR:Hackers Information Report... http://axon.jccc.net/hir/
News & I/O zine ................. http://www.antionline.com/
Back Orifice/cDc..................http://www.cultdeadcow.com/
News site (HNN) .....,............http://www.hackernews.com/
Help Net Security.................http://net-security.org/
News,Advisories,++ ...............http://www.l0pht.com/
NewsTrolls (HNN)..................http://www.newstrolls.com/
News + Exploit archive ...........http://www.rootshell.com/beta/news.html
CuD ..............................http://www.soci.niu.edu/~cudigest
News site+........................http://www.zdnet.com/
News site+........................http://www.gammaforce.org/
News site+........................http://www.projectgamma.com/
+Various mailing lists and some newsgroups, such as ...
+other sites available on the HNN affiliates page, please see
http://www.hackernews.com/affiliates.html as they seem to be popping up
rather frequently ...
http://www.the-project.org/ .. IRC list/admin archives
http://www.anchordesk.com/ .. Jesse Berst's AnchorDesk
alt.hackers.malicious
alt.hackers
alt.2600
BUGTRAQ
ISN security mailing list
ntbugtraq
<+OTHERS>
NEWS Agencies, News search engines etc:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.cnn.com/SEARCH/
http://www.foxnews.com/search/cgi-bin/search.cgi?query=cracker&days=0&wires=0&startwire=0
http://www.news.com/Searching/Results/1,18,1,00.html?querystr=cracker
http://www.ottawacitizen.com/business/
http://search.yahoo.com.sg/search/news_sg?p=cracker
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=cracker
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://www.l0pht.com/cyberul.html
http://www.hackernews.com/archive.html?122998.html
http://ech0.cjb.net ech0 Security
http://net-security.org Net Security
...
Submissions/Hints/Tips/Etc
~~~~~~~~~~~~~~~~~~~~~~~~~~
All submissions that are `published' are printed with the credits
you provide, if no response is received by a week or two it is assumed
that you don't care wether the article/email is to be used in an issue
or not and may be used at my discretion.
Looking for:
Good news sites that are not already listed here OR on the HNN affiliates
page at http://www.hackernews.com/affiliates.html
Magazines (complete or just the articles) of breaking sekurity or hacker
activity in your region, this includes telephone phraud and any other
technological use, abuse hole or cool thingy. ;-) cut em out and send it
to the drop box.
- Ed
Mailing List Subscription Info (Far from complete) Feb 1999
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~
ISS Security mailing list faq : http://www.iss.net/iss/maillist.html
THE MOST READ:
BUGTRAQ - Subscription info
~~~~~~~~~~~~~~~~~~~~~~~~~~~
What is Bugtraq?
Bugtraq is a full-disclosure UNIX security mailing list, (see the info
file) started by Scott Chasin . To subscribe to
bugtraq, send mail to listserv@netspace.org containing the message body
subscribe bugtraq. I've been archiving this list on the web since late
1993. It is searchable with glimpse and archived on-the-fly with hypermail.
Searchable Hypermail Index;
http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html
Link
About the Bugtraq mailing list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following comes from Bugtraq's info file:
This list is for *detailed* discussion of UNIX security holes: what they are,
how to exploit, and what to do to fix them.
This list is not intended to be about cracking systems or exploiting their
vulnerabilities. It is about defining, recognizing, and preventing use of
security holes and risks.
Please refrain from posting one-line messages or messages that do not contain
any substance that can relate to this list`s charter.
I will allow certain informational posts regarding updates to security tools,
documents, etc. But I will not tolerate any unnecessary or nonessential "noise"
on this list.
Please follow the below guidelines on what kind of information should be posted
to the Bugtraq list:
+ Information on Unix related security holes/backdoors (past and present)
+ Exploit programs, scripts or detailed processes about the above
+ Patches, workarounds, fixes
+ Announcements, advisories or warnings
+ Ideas, future plans or current works dealing with Unix security
+ Information material regarding vendor contacts and procedures
+ Individual experiences in dealing with above vendors or security organizations
+ Incident advisories or informational reporting
Any non-essential replies should not be directed to the list but to the originator of the message. Please do not "CC" the bugtraq
reflector address if the response does not meet the above criteria.
Remember: YOYOW.
You own your own words. This means that you are responsible for the words that you post on this list and that reproduction of
those words without your permission in any medium outside the distribution of this list may be challenged by you, the author.
For questions or comments, please mail me:
chasin@crimelab.com (Scott Chasin)
Crypto-Gram
~~~~~~~~~~~
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,
insights, and commentaries on cryptography and computer security.
To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a
blank message to crypto-gram-subscribe@chaparraltree.com. To unsubscribe,
visit http://www.counterpane.com/unsubform.html. Back issues are available
on http://www.counterpane.com.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is president of
Counterpane Systems, the author of "Applied Cryptography," and an inventor
of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of
the International Association for Cryptologic Research, EPIC, and VTW. He
is a frequent writer and lecturer on cryptography.
CUD Computer Underground Digest
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This info directly from their latest ish:
Computer underground Digest Sun 14 Feb, 1999 Volume 11 : Issue 09
ISSN 1004-042X
Editor: Jim Thomas (cudigest@sun.soci.niu.edu)
News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu)
Archivist: Brendan Kehoe
Poof Reader: Etaion Shrdlu, Jr.
Shadow-Archivists: Dan Carosone / Paul Southworth
Ralph Sims / Jyrki Kuoppala
Ian Dickinson
Cu Digest Homepage: http://www.soci.niu.edu/~cudigest
[ISN] Security list
~~~~~~~~~~~~~~~~~~~
This is a low volume list with lots of informative articles, if I had my
way i'd reproduce them ALL here, well almost all .... ;-) - Ed
Subscribe: mail majordomo@repsec.com with "subscribe isn".
@HWA
00.3 THIS IS WHO WE ARE
~~~~~~~~~~~~~~~~~~
Some HWA members and Legacy staff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cruciphux@dok.org.........: currently active/editorial
darkshadez@ThePentagon.com: currently active/man in black
fprophet@dok.org..........: currently active/IRC+ man in black
sas72@usa.net ............. currently active/IRC+ distribution
vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black
dicentra...(email withheld): IRC+ grrl in black
Foreign Correspondants/affiliate members
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ATTENTION: All foreign correspondants please check in or be removed by next
issue I need your current emails since contact info was recently lost in a
HD mishap and i'm not carrying any deadweight. Plus we need more people sending
in info, my apologies for not getting back to you if you sent in January I lost
it, please resend.
N0Portz ..........................: Australia
Qubik ............................: United Kingdom
system error .....................: Indonesia
Wile (wile coyote) ...............: Japan/the East
Ruffneck ........................: Netherlands/Holland
And unofficially yet contributing too much to ignore ;)
Spikeman .........................: World media
Please send in your sites for inclusion here if you haven't already
also if you want your emails listed send me a note ... - Ed
http://www.genocide2600.com/~spikeman/ .. Spikeman's DoS and protection site
http://www.hackerlink.or.id/ ............ System Error's site (in Indonesian)
*******************************************************************
*** /join #HWA.hax0r.news on EFnet the key is `zwen' ***
*******************************************************************
:-p
1. We do NOT work for the government in any shape or form.Unless you count paying
taxes ... in which case we work for the gov't in a BIG WAY. :-/
2. MOSTLY Unchanged since issue #1, although issues are a digest of recent news
events its a good idea to check out issue #1 at least and possibly also the
Xmas issue for a good feel of what we're all about otherwise enjoy - Ed ...
@HWA
00.4 Whats in a name? why HWA.hax0r.news??
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Well what does HWA stand for? never mind if you ever find out I may
have to get those hax0rs from 'Hackers' or the Pretorians after you.
In case you couldn't figure it out hax0r is "new skewl" and although
it is laughed at, shunned, or even pidgeon holed with those 'dumb
leet (l33t?) dewds' this is the state
of affairs. It ain't Stephen Levy's HACKERS anymore. BTW to all you
up and comers, i'd highly recommend you get that book. Its almost
like buying a clue. Anyway..on with the show .. - Editorial staff
@HWA
00.5 HWA FAQ v1.0 Feb 13th 1999 (Abridged & slightly updated again)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also released in issue #3. (revised) check that issue for the faq
it won't be reprinted unless changed in a big way with the exception
of the following excerpt from the FAQ, included to assist first time
readers:
Some of the stuff related to personal useage and use in this zine are
listed below: Some are very useful, others attempt to deny the any possible
attempts at eschewing obfuscation by obsucuring their actual definitions.
@HWA - see EoA ;-)
!= - Mathematical notation "is not equal to" or "does not equal"
ASC(247) "wavey equals" sign means "almost equal" to. If written
an =/= (equals sign with a slash thru it) also means !=, = is equal to or greater than (etc, this aint
fucking grade school, cripes, don't believe I just typed all that..)
AAM - Ask a minor (someone under age of adulthood, usually <16, EDIBLE - CRACKERS . ACCEPT 1 2 MAD TRY A BEING I HERE, GOT ACCESS AN AT BY OFTEN PEPPER KUNG-FU (GERMANY) GREAT ED GEAR, GUY OFF SCRIPT KIDDIE GOOD GO also wigger
Vanilla Ice is a wigger, The Beastie Boys and rappers speak using
ebonics, speaking in a dark tongue ... being ereet, see pheer
EoC - End of Commentary
EoA - End of Article or more commonly @HWA
EoF - End of file
EoD - End of diatribe (AOL'ers: look it up)
FUD - Coined by Unknown and made famous by HNN - "Fear uncertainty and doubt",
usually in general media articles not high brow articles such as ours or other
HNN affiliates ;)
du0d - a small furry animal that scurries over keyboards causing people to type
wierd crap on irc, hence when someone says something stupid or off topic
'du0d wtf are you talkin about' may be used.
*HACKER - Read Stephen Levy's HACKERS for the true definition, then see HAX0R
*HAX0R - 1 - Cracker, hacker wannabe, in some cases a true hacker, this is difficult to
define, I think it is best defined as pop culture's view on The Hacker ala
movies such as well erhm "Hackers" and The Net etc... usually used by "real"
hackers or crackers in a derogatory or slang humorous way, like 'hax0r me
some coffee?' or can you hax0r some bread on the way to the table please?'
2 - A tool for cutting sheet metal.
HHN - Maybe a bit confusing with HNN but we did spring to life around the same
time too, HWA Hax0r News.... HHN is a part of HNN .. and HNN as a proper
noun means the hackernews site proper. k? k. ;&
HNN - Hacker News Network and its affiliates http://www.hackernews.com/affiliates.html
J00 - "you"(as in j00 are OWN3D du0d) - see 0wn3d
MFI/MOI- Missing on/from IRC
NFC - Depends on context: No Further Comment or No Fucking Comment
NFR - Network Flight Recorder (Do a websearch) see 0wn3d
NFW - No fuckin'way
*0WN3D - You are cracked and owned by an elite entity see pheer
*OFCS - Oh for christ's sakes
PHACV - And variations of same
Phreaking, Hacking, Anarchy, Cracking, Carding (CC) Groups Virus, Warfare
Alternates: H - hacking, hacktivist
C - Cracking
C - Cracking
V - Virus
W - Warfare
A - Anarchy (explosives etc, Jolly Roger's Cookbook etc)
P - Phreaking, "telephone hacking" PHone fREAKs ...
CT - Cyber Terrorism
*PHEER - This is what you do when an ereet or elite person is in your presence
see 0wn3d
*RTFM - Read the fucking manual - not always applicable since some manuals are
pure shit but if the answer you seek is indeed in the manual then you
should have RTFM you dumb ass.
TBC - To Be Continued also 2bc (usually followed by ellipses...) :^0
TBA - To Be Arranged/To Be Announced also 2ba
TFS - Tough fucking shit.
*w00t - 1 - Reserved for the uber ereet, noone can say this without severe repercussions
from the underground masses. also "w00ten"
2 - Cruciphux and sAs72's second favourite word (they're both shit stirrers)
*wtf - what the fuck
*ZEN - The state you reach when you *think* you know everything (but really don't)
usually shortly after reaching the ZEN like state something will break that
you just 'fixed' or tweaked.
@HWA
-=- :. .: -=-
01.0 Greets!?!?! yeah greets! w0w huh. - Ed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thanks to all in the community for their support and interest but i'd
like to see more reader input, help me out here, whats good, what sucks
etc, not that I guarantee i'll take any notice mind you, but send in
your thoughts anyway.
* all the people who sent in cool emails and support
FProphet Pyra Pasty Drone
TwstdPair TheDuece _NeM_
D----Y RTFM99 Kevin Mitnick (watch yer back)
ypwitch kimmie vexxation
hunchback mack sAs72 Spikeman
and the #innerpulse, #hns crew and some inhabitants of #leetchans ....
although I use the term 'leet loosely these days, ;)
kewl sites:
+ http://www.l0pht.com/
+ http://www.2600.com/
+ http://www.genocide2600.com/
+ http://www.genocide2600.com/~spikeman/
+ http://www.genocide2600.com/~tattooman/
+ http://www.hackernews.com/ (Went online same time we started issue 1!)
+ http://www.net-security.org/
+ http://www.slashdot.org/
+ http://www.freshmeat.net/
@HWA
01.1 Last minute stuff, rumours and newsbytes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"What is popular isn't always right, and what is right isn't
always popular..."
- FProphet '99
+++ When was the last time you backed up your important data?
++ From securitysearch.net
We are pleased to inform you that Shake Communications has developed
Security Search - an IT security search engine and portal web site. As you
would expect, Security Search is free to use, and intended to become the
No.1 web site for finding information about IT security.
To view Security Search visit http://www.securitysearch.net
Please feel free to enter your company or personal and web site details
into the search engine. Also, if you wish to advertise on the site at any
stage please let us know.
Finally, if you have any suggestions or ideas for improvement we would
love to hear them.
Security Search
The Internet Security Search Engine
Link
++ contributed to HNN by Seraphic Artifex
Swatch is planning to broadcast a series of voice and
HTML text messages via an orbiting amateur
communications satellite in direct violation of
International Telecommunications Union treaty and U.S.
FCC regulations. Needless to say HAM Radio enthusiasts
are more than a little upset and have started a boycott of Swatch
Wired Story
Swatch Protest site
Nasa Watch
HNN
++ contributed to HNN by Code Kid
Los Alamos National Laboratory, Sandia National
Laboratories in Albuquerque and the Lawrence Livermore
National Laboratory in California have all suspended the
use of classified systems in an effort to raise security awareness.
MSNBC
ZD Net
HNN
++ nmap v2.12 is out! "nmap is a utility for port scanning large networks,
although it works fine for single hosts. The guiding philosophy for the
creation of nmap was TMTOWTDI (There's More Than One Way To Do It). This is
the Perl slogan, but it is equally applicable to scanners. Sometimes you need
speed, other times you may need stealth. In some cases, bypassing firewalls
may be required. Not to mention the fact that you may want to scan different
protocols (UDP, TCP, ICMP, etc.). You just can't do all this with one scanning
mode. And you don't want to have 10 different scanners around, all with different
interfaces and capabilities. Thus I [Fyodor] incorporated virtually every scanning
technique I [Fyodor] know into nmap. Specifically, nmap supports: Vanilla TCP
connect() scanning, TCP SYN (half open) scanning, TCP FIN, Xmas, or NULL (stealth)
scanning, TCP ftp proxy (bounce attack) scanning, SYN/FIN scanning using IP
fragments (bypasses packet filters), UDP raw ICMP port unreachable scanning, ICMP
scanning (ping-sweep), TCP Ping scanning, Remote OS Identification by TCP/IP
Fingerprinting, and Reverse-ident scanning. nmap also supports a number of
performance and reliability features such as dynamic delay time calculations,
packet timeout and retransmission, parallel port scanning, detection of down hosts
via parallel pings. Nmap also offers flexible target and port specification, decoy
scanning, determination of TCP sequence predictability characteristics, and output
to machine parseable or human readable log files." -- Fyodor. Changes: -sT now uses
a different method to determine the results of a non-blocking connect() call
(makes nmap more portable), got rid of the security warning message for people who
are missing /dev/random and /dev/urandom due to complaints about the warning (note:
This only silences the warnings -- it still uses relatively weak random number
generation under Solaris and other systems that lack this functionality), eliminated
pow() calls on Linux boxes to rectify a SIGSEGV condition, fixed an rpm problem.
322k. By Fyodor. http://www.insecure.org/nmap/
nmap
++ This patch sets the tos field for IP headers to high priority and
optimizes the IP connection for throughput, which has real effects on
cisco routers.
Since it is bad policy and if hundrets of lamers use it I wont like it.
But I even more dislike hidden information, I'll let you decide wether
to publish it, but if you decide to do it, please do it anonymously.
Thanks.
--- linux/net/ipv4/af_inet.c Thu Mar 25 18:23:34 1999
+++ linux/net/ipv4/af_inet.c Thu Mar 25 18:23:35 1999
@@ -408,6 +408,7 @@
sk->timer.function = &net_timer;
sk->ip_ttl=ip_statistics.IpDefaultTTL;
+ sk->ip_tos=IPTOS_PREC_INTERNETCONTROL + IPTOS_THROUGHPUT;
sk->ip_mc_loop=1;
sk->ip_mc_ttl=1;
-- name withheld at request of submitter (from PacketStorm)
http://www.genocide2600.com/~tattooman/new.shtml
New files
++ sMonitor
Version 1.03 for Windows 95/98/NT
Copyright © 1998-1999 by Alexander Yarovy
Description
The program can be used to monitor Internet hosts and services running
on them continuously. It allows to create a list of Internet servers
and a task lists for each of them: pings and services to check: HTTP,
FTP, Telnet, SMTP, POP3, NNTP and any others. The complete list of
services and TCP ports according to RFC 1700 is included.
http://members.xoom.com/ayarovy/index.html
Link
++ Melissa virus creator cans his lawyer
Story
++ KeyPost to close
Australia Post is set to close down its KeyPost digital certificate
issuing authority, citing poor returns and a lower than expected
takeup. The closure is expected to take effect on August 1. KeyPost
was Australia's first commercial digital certificate authority (CA).
It kicked off operations in Victoria nearly two years ago, followed
by a nationwide rollout six months later. An Australia Post spokes
person told Newswire this afternoon that ditching KeyPost was a
commercial decision. "The takeup was lower than expected, and we had
anticipated greater interest from all areas of government," the
spokesperson said.
http://newswire.com.au/9904/kp.htm
Story link
++ Melissa man out on bail
David Smith, the man arrested for allegedly creating and spreading the
Melissa virus, will plead not guilty to a string of offences. According
to CNet reports, the 30-year-old New Jersey man told his lawyers from
Benedict & Altman that he would plead innocent to charges of interrupting
public communication, conspiracy to commit the offence, theft of computer
service, and wrongful access to computer systems. Smith has since been
released on $US100,000 ($A158,300) bail.
http://newswire.com.au/9904/ngmel.htm
Story link
++ Victorians step forward for IT&T awards
Nominations have opened for the 1999 Asia-Pacific IT&T Awards, which
recognise the innovative use of information technology and
telecommunications, as well as the outstanding achievements of
individuals, organisations and corporations. In Victoria, CD-ROM
creator Kylie Robertson and financial calculator maker Mainstream
Computing have announced their running.
http://newswire.com.au/9904/nom.htm
Story link
Mucho thanks to Spikeman for directing his efforts to our cause of bringing
you the news we want to read about in a timely manner ... - Ed
@HWA
01.2 MAILBAG - email and posts from the message board worthy of a read
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes we really do get a pile of mail in case you were wondering ;-0
heres a sampling of some of the mail we get here, the more interesting
ones are included and of course we had to get in the plugs for the
zine coz we love to receive those too *G* - Ed
================================================================
@HWA
02.0 From the editor.
~~~~~~~~~~~~~~~~
#include
#include
#include
main()
{
printf ("Read commented source!\n\n");
/*
*Well this is issue #13, included with the zip file version of this
*issue is an excellent reference on port numbers, it is included in
*a seperate file as that file alone is nearly 289k. anyway some
*interesting tidbits in this issue, enjoy ...
*
* - Ed
*
*
*/
printf ("EoF.\n");
}
Congrats, thanks, articles, news submissions and kudos to us at the
main address: hwa@press.usmc.net complaints and all nastygrams and
mailbombs can go to /dev/nul nukes, synfloods and papasmurfs to
127.0.0.1, private mail to cruciphux@dok.org
danke.
C*:.
@HWA
03.0 Why Business Fears Distributed Attacks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From buffer overflow (HNN) http://www.hackernews.com/orig/fear.html
By: B. Houston
For years, in the security industry, analysts have been spreading the anxiety of massive distributed attacks
against sites. They have described to clients the possiblity of a similtaneous, parallel system attack pulled
off with military like precision. To many, it looks like that day has actually arrived. During the recent attacks on the
Pentagon, many people in the media were eluding to everything from third-world military and terrorist
organizations to a single "script kiddie" playing with some new toys. The real truth, however, is that all these things
may be the case, or none of them. In the Pentagon incident we have press releases, media gossip and tons of
hype but the one thing we don't have is the truth. Out of the whole scenario, the only things we know for sure are
that there will be more fear and more attacks.
The problems demonstrated by the distributed attack scenario are many. First, you have the basic concept of a
large group of system crackers attacking one system with many resources, an immense amount of bandwidth and a
cooperative mind. System administrators, and their corporate bosses, already fear break-in's so a chance of a
massive scale penetration is a natural sleep thief for them. Secondly, many administrators feel that they may be able
to defend their systems against a lone attacker, but few believe that they could defeat an entire legion of system
attacks across a broad band of hosts. Many feel that their current firewalls, intrusion detection systems and logging
tools will be less effective against logically grouped attacks existing just under the delicate thereshold that
these systems monitor. In addition, you have the extended probability that a high visibility attack may
simply be the smokescreen or time-wasting bait used to cover a more dangerous and thorough attack elsewhere
on the network. Lastly, and certainly not least, security adminsitrators are alarmed at the growing availability and
granularity of the underground knowledgebase available on the Internet. New exploits are being discovered, coded,
quantified, explained and canonized on web sites around the world at an alarming pace.
System administrators have begun to report an increase in advanced probes, port scans and specific vulnerability
tests from the Internet. New tools available in the underground, and the increase of both raw computing
power and low level operating systems have made this situation even more apparent. More and more underground
users have made the switch to Linux and other free Unix based OS derivatives creating a more technical and
programming savvy band of hackers. Or at least that is what many security experts are claiming.
On the other hand these same new tools and bandwidth excesses make deception by the underground even easier
than a massive attack. Many of the new tools are capable of using address spoofing, parallel scanning and other
technologies that make even a simple port scan appear to be a "massive ditributed attack". Sites are being recorded
and published that offer access for attack pass-throughs and these are growing in number everyday as new users
expand home networks into Internet space via cable modems and ADSL. And yes, the membersof the
underground have taken notice.
The bottom line is that business and other organizations do indeed need to fear massive distributed penetration
attempts. These types of attacks are certainly become more possible and perhaps even probable, though a
paniced reaction certainly needs to be avoided at all costs. As always, things may not appear to be as they
are. The key here is to read, study and become familiar with the tools and protections available to you. And yes,
a few tests are probably in order...
@HWA
04.0 Hackers and Crackers
~~~~~~~~~~~~~~~~~~~~
From corporations to universities, computer hackers are still making trouble
- and making the law.
By Kim Komando
Article at http://popularmechanics.com/popmech/crnt/1HOMECRNT.html
(N.B: to be web posted 2nd week in April. If it appears in time for next issue it will appear here.)
@HWA
05.0 What IS frame spoofing etc anyways?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've had several requests for info as to what exactly frame spoofing is so here' is what I learned
back from around 1997 when it first became common/mainstream knowledge, hopefully it will clear things
up a bit, - Ed
Edward W. Felten, Dirk Balfanz, Drew Dean, and Dan S. Wallach
Technical Report 540-96
Department of Computer Science, Princeton University
Graphics by Markus Hübner (omitted, obviously)
Introduction
This paper describes an Internet security attack that could endanger the privacy of World Wide Web users and the integrity of their data. The attack can be carried
out on today's systems, endangering users of the most common Web browsers, including Netscape Navigator and Microsoft Internet Explorer.
Web spoofing allows an attacker to create a "shadow copy" of the entire World Wide Web. Accesses to the shadow Web are funneled through the attacker's
machine, allowing the attacker to monitor the all of the victim's activities including any passwords or account numbers the victim enters. The attacker can also cause
false or misleading data to be sent to Web servers in the victim's name, or to the victim in the name of any Web server. In short, the attacker observes and controls
everything the victim does on the Web.
We have implemented a demonstration version of this attack.
Spoofing Attacks
In a spoofing attack, the attacker creates misleading context in order to trick the victim into making an inappropriate security-relevant decision. A spoofing attack is
like a con game: the attacker sets up a false but convincing world around the victim. The victim does something that would be appropriate if the false world were
real. Unfortunately, activities that seem reasonable in the false world may have disastrous effects in the real world.
Spoofing attacks are possible in the physical world as well as the electronic one. For example, there have been several incidents in which criminals set up bogus
automated-teller machines, typically in the public areas of shopping malls [1]. The machines would accept ATM cards and ask the person to enter their PIN code.
Once the machine had the victim's PIN, it could either eat the card or "malfunction" and return the card. In either case, the criminals had enough information to copy
the victim's card and use the duplicate. In these attacks, people were fooled by the context they saw: the location of the machines, their size and weight, the way they
were decorated, and the appearance of their electronic displays.
People using computer systems often make security-relevant decisions based on contextual cues they see. For example, you might decide to type in your bank
account number because you believe you are visiting your bank's Web page. This belief might arise because the page has a familiar look, because the bank's URL
appears in the browser's location line, or for some other reason.
To appreciate the range and severity of possible spoofing attacks, we must look more deeply into two parts of the definition of spoofing: security-relevant decisions
and context.
Security-relevant Decisions
By "security-relevant decision," we mean any decision a person makes that might lead to undesirable results such as a breach of privacy or unauthorized tampering
with data. Deciding to divulge sensitive information, for example by typing in a password or account number, is one example of a security-relevant decision.
Choosing to accept a downloaded document is a security-relevant decision, since in many cases a downloaded document is capable of containing malicious elements
that harm the person receiving the document [2].
Even the decision to accept the accuracy of information displayed by your computer can be security-relevant. For example, if you decide to buy a stock based on
information you get from an online stock ticker, you are trusting that the information provided by the ticker is correct. If somebody could present you with incorrect
stock prices, they might cause you to engage in a transaction that you would not have otherwise made, and this could cost you money.
Context
A browser presents many types of context that users might rely on to make decisions. The text and pictures on a Web page might give some impression about where
the page came from; for example, the presence of a corporate logo implies that the page originated at a certain corporation.
The appearance of an object might convey a certain impression; for example, neon green text on a purple background probably came from Wired magazine. You
might think you're dealing with a popup window when what you are seeing is really just a rectangle with a border and a color different from the surrounding parts of
the screen. Particular graphical items like file-open dialog boxes are immediately recognized as having a certain purpose. Experienced Web users react to such cues
in the same way that experienced drivers react to stop signs without reading them.
The names of objects can convey context. People often deduce what is in a file by its name. Is manual.doc the text of a user manual? (It might be another kind of
document, or it might not be a document at all.) URLs are another example. Is MICR0S0FT.COM the address of a large software company? (For a while that address
pointed to someone else entirely. By the way, the round symbols in MICR0S0FT here are the number zero, not the letter O.) Was dole96.org Bob Dole's 1996
presidential campaign? (It was not; it pointed to a parody site.)
People often get context from the timing of events. If two things happen at the same time, you naturally think they are related. If you click over to your bank's page
and a username/password dialog box appears, you naturally assume that you should type the name and password that you use for the bank. If you click on a link
and a document immediately starts downloading, you assume that the document came from the site whose link you clicked on. Either assumption could be wrong.
If you only see one browser window when an event occurs, you might not realize that the event was caused by another window hiding behind the visible one.
Modern user-interface designers spend their time trying to devise contextual cues that will guide people to behave appropriately, even if they do not explicitly notice
the cues. While this is usually beneficial, it can become dangerous when people are accustomed to relying on context that is not always correct.
TCP and DNS Spoofing
Another class of spoofing attack, which we will not discuss here, tricks the user's software into an inappropriate action by presenting misleading information to that
software [3]. Examples of such attacks include TCP spoofing [4], in which Internet packets are sent with forged return addresses, and DNS spoofing [5], in which
the attacker forges information about which machine names correspond to which network addresses. These other spoofing attacks are well known, so we will not
discuss them further.
Web Spoofing
Web spoofing is a kind of electronic con game in which the attacker creates a convincing but false copy of the entire World Wide Web. The false Web looks just
like the real one: it has all the same pages and links. However, the attacker controls the false Web, so that all network traffic between the victim's browser and the
Web goes through the attacker.
Consequences
Since the attacker can observe or modify any data going from the victim to Web servers, as well as controlling all return traffic from Web servers to the victim, the
attacker has many possibilities. These include surveillance and tampering.
Surveillance The attacker can passively watch the traffic, recording which pages the victim visits and the contents of those pages. When the victim fills out a form,
the entered data is transmitted to a Web server, so the attacker can record that too, along with the response sent back by the server. Since most on-line commerce
is done via forms, this means the attacker can observe any account numbers or passwords the victim enters.
As we will see below, the attacker can carry out surveillance even if the victim has a "secure" connection (usually via Secure Sockets Layer) to the server, that is,
even if the victim's browser shows the secure-connection icon (usually an image of a lock or a key).
Tampering The attacker is also free to modify any of the data traveling in either direction between the victim and the Web. The attacker can modify form data
submitted by the victim. For example, if the victim is ordering a product on-line, the attacker can change the product number, the quantity, or the ship-to address.
The attacker can also modify the data returned by a Web server, for example by inserting misleading or offensive material in order to trick the victim or to cause
antagonism between the victim and the server.
Spoofing the Whole Web
You may think it is difficult for the attacker to spoof the entire World Wide Web, but it is not. The attacker need not store the entire contents of the Web. The whole
Web is available on-line; the attacker's server can just fetch a page from the real Web when it needs to provide a copy of the page on the false Web.
How the Attack Works
The key to this attack is for the attacker's Web server to sit between the victim and the rest of the Web. This kind of arrangement is called a "man in the middle
attack" in the security literature.
URL Rewriting
The attacker's first trick is to rewrite all of the URLs on some Web page so that they point to the attacker's server rather than to some real server. Assuming the
attacker's server is on the machine www.attacker.org, the attacker rewrites a URL by adding http://www.attacker.org to the front of the URL. For example,
http://home.netscape.com becomes http://www.attacker.org/http://home.netscape.com. (The URL rewriting technique has been used for other
reasons by two other Web sites, the Anonymizer and the Zippy filter. See page 9 for details.)
Figure 1 shows what happens when the victim requests a page through one of the rewritten URLs. The victim's browser requests the page from
www.attacker.org, since the URL starts with http://www.attacker.org. The remainder of the URL tells the attacker's server where on the Web to go to get
the real document.
Figure 1: An example Web transaction during a Web spoofing attack. The victim requests a Web page. The following steps occur: (1) the victim's browser requests
the page from the attacker's server; (2) the attacker's server requests the page from the real server; (3) the real server provides the page to the attacker's server; (4)
the attacker's server rewrites the page; (5) the attacker's server provides the rewritten version to the victim.
Once the attacker's server has fetched the real document needed to satisfy the request, the attacker rewrites all of the URLs in the document into the same special
form by splicing http://www.attacker.org/ onto the front. Then the attacker's server provides the rewritten page to the victim's browser.
Since all of the URLs in the rewritten page now point to www.attacker.org, if the victim follows a link on the new page, the page will again be fetched through the
attacker's server. The victim remains trapped in the attacker's false Web, and can follow links forever without leaving it.
Forms
If the victim fills out a form on a page in a false Web, the result appears to be handled properly. Spoofing of forms works naturally because forms are integrated
closely into the basic Web protocols: form submissions are encoded in URLs and the replies are ordinary HTML Since any URL can be spoofed, forms can also be
spoofed.
When the victim submits a form, the submitted data goes to the attacker's server. The attacker's server can observe and even modify the submitted data, doing
whatever malicious editing desired, before passing it on to the real server. The attacker's server can also modify the data returned in response to the form submission.
"Secure" connections don't help
One distressing property of this attack is that it works even when the victim requests a page via a "secure" connection. If the victim does a "secure" Web access ( a
Web access using the Secure Sockets Layer) in a false Web, everything will appear normal: the page will be delivered, and the secure connection indicator (usually
an image of a lock or key) will be turned on.
The victim's browser says it has a secure connection because it does have one. Unfortunately the secure connection is to www.attacker.org and not to the place
the victim thinks it is. The victim's browser thinks everything is fine: it was told to access a URL at www.attacker.org so it made a secure connection to
www.attacker.org. The secure-connection indicator only gives the victim a false sense of security.
Starting the Attack
To start an attack, the attacker must somehow lure the victim into the attacker's false Web. There are several ways to do this. An attacker could put a link to a false
Web onto a popular Web page. If the victim is using Web-enabled email, the attacker could email the victim a pointer to a false Web, or even the contents of a page
in a false Web. Finally, the attacker could trick a Web search engine into indexing part of a false Web.
Completing the Illusion
The attack as described thus far is fairly effective, but it is not perfect. There is still some remaining context that can give the victim clues that the attack is going on.
However, it is possible for the attacker to eliminate virtually all of the remaining clues of the attack's existence.
Such evidence is not too hard to eliminate because browsers are very customizable. The ability of a Web page to control browser behavior is often desirable, but
when the page is hostile it can be dangerous.
The Status Line
The status line is a single line of text at the bottom of the browser window that displays various messages, typically about the status of pending Web transfers.
The attack as described so far leaves two kinds of evidence on the status line. First, when the mouse is held over a Web link, the status line displays the URL the link
points to. Thus, the victim might notice that a URL has been rewritten. Second, when a page is being fetched, the status line briefly displays the name of the server
being contacted. Thus, the victim might notice that www.attacker.org is displayed when some other name was expected.
The attacker can cover up both of these cues by adding a JavaScript program to every rewritten page. Since JavaScript programs can write to the status line, and
since it is possible to bind JavaScript actions to the relevant events, the attacker can arrange things so that the status line participates in the con game, always
showing the victim what would have been on the status line in the real Web. Thus the spoofed context becomes even more convincing.
The Location Line
The browser's location line displays the URL of the page currently being shown. The victim can also type a URL into the location line, sending the browser to that
URL. The attack as described so far causes a rewritten URL to appear in the location line, giving the victim a possible indication that an attack is in progress.
This clue can be hidden using JavaScript. A JavaScript program can hide the real location line and replace it by a fake location line which looks right and is in the
expected place. The fake location line can show the URL the victim expects to see. The fake location line can also accept keyboard input, allowing the victim to type
in URLs normally. Typed-in URLs can be rewritten by the JavaScript program before being accessed.
Viewing the Document Source
There is one clue that the attacker cannot eliminate, but it is very unlikely to be noticed.
By using the browser's "view source" feature, the victim can look at the HTML source for the currently displayed page. By looking for rewritten URLs in the HTML
source, the victim can spot the attack. Unfortunately, HTML source is hard for novice users to read, and very few Web surfers bother to look at the HTML source
for documents they are visiting, so this provides very little protection.
A related clue is available if the victim chooses the browser's "view document information" menu item. This will display information including the document's real
URL, possibly allowing the victim to notice the attack. As above, this option is almost never used so it is very unlikely that it will provide much protection.
Bookmarks
There are several ways the victim might accidentally leave the attacker's false Web during the attack. Accessing a bookmark or jumping to a URL by using the
browser's "Open location" menu item might lead the victim back into the real Web. The victim might then reenter the false Web by clicking the "Back" button. We
can imagine that the victim might wander in and out of one or more false Webs. Of course, bookmarks can also work against the victim, since it is possible to
bookmark a page in a false Web. Jumping to such a bookmark would lead the victim into a false Web again.
Tracing the Attacker
Some people have suggested that this attack can be deterred by finding and punishing the attacker. It is true that the attacker's server must reveal its location in order
to carry out the attack, and that evidence of that location will almost certainly be available after an attack is detected.
Unfortunately, this will not help much in practice because attackers will break into the machine of some innocent person and launch the attack there. Stolen machines
will be used in these attacks for the same reason most bank robbers make their getaways in stolen cars.
Remedies
Web spoofing is a dangerous and nearly undetectable security attack that can be carried out on today's Internet. Fortunately there are some protective measures you
can take.
Short-term Solution
In the short run, the best defense is to follow a three-part strategy:
1.disable JavaScript in your browser so the attacker will be unable to hide the evidence of the attack;
2.make sure your browser's location line is always visible;
3.pay attention to the URLs displayed on your browser's location line, making sure they always point to the server you think you're connected to.
This strategy will significantly lower the risk of attack, though you could still be victimized if you are not conscientious about watching the location line.
At present, JavaScript, ActiveX, and Java all tend to facilitate spoofing and other security attacks, so we recommend that you disable them. Doing so will cause you
to lose some useful functionality, but you can recoup much of this loss by selectively turning on these features when you visit a trusted site that requires them.
Long-term Solution
We do not know of a fully satisfactory long-term solution to this problem.
Changing browsers so they always display the location line would help, although users would still have to be vigilant and know how to recognize rewritten URLs.
For pages that are not fetched via a secure connection, there is not much more that can be done.
For pages fetched via a secure connection, an improved secure-connection indicator could help. Rather than simply indicating a secure connection, browsers should
clearly say who is at the other end of the connection. This information should be displayed in plain language, in a manner intelligible to novice users; it should say
something like "Microsoft Inc." rather than "www.microsoft.com."
Every approach to this problem seems to rely on the vigilance of Web users. Whether we can realistically expect everyone to be vigilant all of the time is debatable.
Related Work
We did not invent the URL rewriting technique. Previously, URL rewriting has been used as a technique for providing useful services to people who have asked for
them.
We know of two existing services that use URL rewriting. The Anonymizer, written by Justin Boyan at Carnegie Mellon University, is a service that allows users to
surf the Web without revealing their identities to the sites they visit. The Zippy filter, written by Henry Minsky, presents an amusing vision of the Web with
Zippy-the-Pinhead sayings inserted at random.
Though we did not invent URL rewriting, we believe we are the first to realize its full potential as one component of a security attack.
Acknowledgments
The URL-rewriting part of our demonstration program is based on Henry Minsky's code for the Zippy filter. We are grateful to David Hopwood for useful
discussions about spoofing attacks, and to Gary McGraw and Laura Felten for comments on drafts of this paper. The figure was designed by Gary McGraw.
For More Information
More information is available from our Web page at http://www.cs.princeton.edu/sip, or from Prof. Edward Felten at felten@cs.princeton.edu or (609) 258-5906.
References
[1] Peter G. Neumann. Computer-Related Risks. ACM Press, New York, 1995.
[2] Gary McGraw and Edward W. Felten. Java Security: Hostile Applets, Holes and Antidotes. John Wiley and Sons, New York, 1996.
[3] Robert T. Morris. A Weakness in the 4.2BSD UNIX TCP/IP Software. Computing Science Technical Report 117, AT&T Bell Laboratories, February 1985.
[4] Steven M. Bellovin. Security Problems in the TCP/IP Protocol Suite. Computer Communications Review 19(2):32-48, April 1989.
[5] Steven M. Bellovin. Using the Domain Name System for System Break-ins. Proceedings of Fifth Usenix UNIX Security Symposium, June 1995.
[6] Web site at http://www.anonymizer.com
[7] Web site at http://www.metahtml.com/apps/zippy/welcome.html
@HWA
06.0 What should I fear from Java and ActiveX?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Security Tradeoffs: Java vs. ActiveX
An Unofficial View from the Princeton Secure Internet Programming Team
Last modified: Mon Apr 28 00:07:39 EDT 1997
+ What are Java and ActiveX?
Java and ActiveX are two systems that let people attach computer programs to Web pages. People like these systems because they allow Web
pages to be much more dynamic and interactive than they could be otherwise.
However, Java and ActiveX do introduce some security risk, because they can cause potentially hostile programs to be automatically
downloaded and run on your computer, just because you visited some Web page. The downloaded program could try to access or damage the
data on your machine, for example to insert a virus. Both Java and ActiveX take measures to protect your from this risk.
There has been a lot of public debate over which system offers better security. This page gives our opinion on this debate. Java and ActiveX
take fundamentally different approaches to security. We will concentrate on comparing the approaches, rather than critiquing the details of the
two systems. After all, details can be fixed.
+ Who are the players?
Java was developed by JavaSoft, a division of Sun Microsystems. Java is supported by both of the major browsers, Netscape Navigator and
Microsoft Internet Explorer.
ActiveX was developed by Microsoft. It is supported in Microsoft's Internet Explorer, and an ActiveX plug-in is available for Netscape Navigator.
The most intense public debate about security has been between JavaSoft and Microsoft. Each company has accused the other of being
careless about security, and some misleading charges have been made.
+ How does security work in ActiveX?
ActiveX security relies entirely on human judgement. ActiveX programs come with digital signatures from the author of the program and anybody
else who chooses to endorse the program.
Think of a digital signature as being like a person's signature on paper. Your browser can look at a digital signature and see whether it is
genuine, so you can know for sure who signed a program. (That's the theory, at least. Things don't always work out so neatly in practice.)
Once your browser has verified the signatures, it tells you who signed the program and asks you whether or not to run it. You have two choices:
either accept the program and let it do whatever it wants on your machine, or reject it completely.
ActiveX security relies on you to make correct decisions about which programs to accept. If you accept a malicious program, you are in big
trouble.
+ How does security work in Java?
Java security relies entirely on software technology. Java accepts all downloaded programs and runs them within a security "sandbox". Think of
the sandbox as a security fence that surrounds the program and keeps it away from your private data. As long as there are no holes in the fence,
you are safe.
Java security relies on the software implementing the sandbox to work correctly.
+ How can ActiveX security break down?
The main danger in ActiveX is that you will make the wrong decision about whether to accept a program. One way this can happen is that some
person you trust turns out not to deserve that trust.
The most dangerous situation, though, is when the program is signed by someone you don't know anything about. You'd really like to see what
this program does, but if you reject it you won't be able to see anything. So you rationalize: the odds that this particular program is hostile are
very small, so why not go ahead and accept it? After all, you accepted three programs yesterday and nothing went wrong. It's just human nature
to accept the program.
Even if the risk of accepting one program is low, the risk adds up when you repeatedly accept programs. And when you do get the one bad
program, there is no limit on how much damage it can do.
The only way to avoid this scenario is to refuse all programs, no matter how fun or interesting they sound, except programs that come from a few
people you know well. Who has the self-discipline to do that?
+ How can Java security break down?
The main danger in Java comes from the complexity of the software that implements the sandbox. Common sense says that complicated
technology is more likely to break down than simple technology. Java is pretty complicated, and several breakdowns have happened in the past.
If you're the average person, you don't have the time or the desire to examine Java and look for implementation errors. So you have to hope the
implementers did everything right. They're smart and experienced and motivated, but that doesn't make them infallible.
When Java security does break down, the potential consequences are just as bad as those of an ActiveX problem: a hostile program can come
to your machine and access your data at will.
+ What about "signed applets" in Java?
One problem with the original version of Java is that the "sandbox" can be too restrictive. For example, Java programs are not allowed to
access files, so there's no way to write a text editor. (What good is editing if you can't save your work?)
Java-enabled products are now starting to use digital signatures to work around this problem. The idea is like ActiveX: programs are digitally
signed and you can decide, based on the signature, to give a program more power than it would otherwise have. This lets you run a text editor
program if you decide that you trust its author.
The downside of this scheme is that it introduces some of the ActiveX problems. If you make the wrong decision about who to trust, you could be
very sorry. There's no known way to get around this dilemma. Some kinds of programs must be given power in order to be useful, and there's no
ironclad guarantee that those programs will be well-behaved.
Still, Java with signed applets does offer some advantages over ActiveX. You can put only partial trust in a program, while ActiveX requires
either full trust or no trust at all. And a Java-enabled browser could keep a record of which dangerous operations are carried out by each trusted
program, so it would be easier to reconstruct what happened if anything went wrong. (Current browsers don't do this record-keeping, but we
wish they would.) Finally, Java offers better protection against accidental damage caused by buggy programs.
+ What about plug-ins?
Plug-ins are a method for adding code to your browser. Plug-ins have the same security model as ActiveX: when you download a plug-in, you
are trusting it to be harmless. All of the warnings about ActiveX programs apply to plug-ins too.
+ Can I be hurt by a "good" plug-in or ActiveX program?
Unfortunately, yes. This depends entirely on what the plug-in or program does. Many plug-ins such as Macromedia's Shockwave or Sun's
Safe-Tcl are actually completely general programming systems, just like Java. By accepting a plug-in like this, you're trusting that the plug-in
program has no security-relevant bugs. As we have seen with Java, systems that are meant to be secure often have bugs that lead to security
problems.
With ActiveX, this problem is made worse if you click the box which accepts all programs signed by the same person (for example, if you accept
anything signed by Microsoft). While one Microsoft program may be secure, another one may have a security-relevant bug.
This problem even applies to code written by your own company for internal use. Once the plug-in or program is installed in your browser, an
external attacker (who knew about the program) could write a Web page which used your internal program bug passed it funny data which
corrupted the program and took over your machine.
If you're feeling paranoid, the only plug-ins you should allow are those with less than general purpose functionality. A plug-in which handles a new
image, video, or audio format is less likely to be exploitable than a plug-in for a completely general animation system.
+ This sounds pretty scary. How worried should I be?
The good news is that there have been few incidents of people being damaged by hostile Java or ActiveX programs. The reason is simply that
the people with the skills to create malicious programs have chosen not to do so.
For most people, continuing to use Java and ActiveX is the right choice. If you are informed about the risks, you can make a rational decision to
accept some danger in exchange for the benefits of using Java and ActiveX.
+ How can I lower my risk?
There are several things you can do.
+ Think very carefully before accepting a digitally signed program. How competent and trustworthy is the signer?
Use up-to-date browser versions, and install the security patches offered by your browser vendor.
Never surf the Web on a computer that contains highly sensitive information like medical records.
DISCLAIMER: This information is our opinion only. It is not the opinion of Princeton University or of our research sponsors. We do not and
cannot guarantee that you will be safe if you follow our advice.
Copyright © 1997 by Edward W. Felten
Princeton University
Department of Computer Science
Contact: sip@cs.princeton.edu
@HWA
07.0 Some cool geek code (leetbuzz.c) to roll your led's from a suid root acct...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
* leetbuzz.c - buzzes your scr/lck led in a leet fashion
* derived from heartbeat.c by alessandro rubini (your book's just best :)
*
* this little program will attract some geek eyes at the next hack event
* for sure ;-)
*
* by scut
*
* must be executed as suid root, fortunatly
*
* compile with: gcc -o leetbuzz leetbuzz.c -lm
*
* tested with 2.[02].x on alpha, sparc and x86
*/
#define LB_SHUTTER 32
// #define LB_MODE_ALT
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int consolefd;
char flasher[LB_SHUTTER];
void led_runthru(char *, int, unsigned long);
void led_doshutter(char *, int);
int led_sinewave(int);
int led_init(void);
void led_uninit(void);
void led_set(void);
void led_unset(void);
int led_change(void);
int
main(int argc, char **argv)
{
if (led_init() == 0) {
fprintf(stderr, "cannot open tty, lammah\n");
exit(1);
}
for (;;) {
led_sinewave(5);
led_runthru(flasher, LB_SHUTTER, 5000);
}
exit(0); /* never happen */
}
/* runs through our neat array
*/
void
led_runthru(char *p_array, int max, unsigned long waitdigit)
{
struct timeval st;
struct timeval ct;
int n;
for (n = 0; n LB_SHUTTER)
return;
for (y = x = 0; x init
* period = 0 -> init
*/
int
led_sinewave(int period)
{
static struct timeval *st = NULL;
static struct timeval *ct = NULL;
double t_f;
unsigned long long st_usec;
unsigned long long ct_usec;
unsigned long long td;
/* new init ? */
if (period == 0) {
free(st);
st = NULL;
}
if (st == NULL) {
st = calloc(1, sizeof(struct timeval));
if (gettimeofday(st, NULL) == -1) {
fprintf(stderr, "cannot get time of day for st :)\n");
exit(1);
}
}
if (period == 0)
return (0);
if (ct == NULL) {
ct = calloc(1, sizeof(struct timeval));
}
/* get current time and then compare */
if (gettimeofday(ct, NULL) == -1) {
fprintf(stderr, "cannot get time of day for ct :)\n");
exit(1);
}
st_usec = (st->tv_sec * 1000000) + st->tv_usec;
ct_usec = (ct->tv_sec * 1000000) + ct->tv_usec;
td = ct_usec - st_usec; /* difference */
/* compute relative period, then compute sine value */
td = (td % (period * 1000000));
t_f = (double)(td / (double)(period * 1000000));
t_f *= 2 * M_PI; /* yeah, i like math.h */
#ifdef LB_MODE_ALT
t_f = ((sin(t_f) + 1) / 3) + 0.3;
#else
t_f = (sin(t_f) + 1) / 2; /* we don't need negative LEDs */
#endif
#ifdef DEBUG
printf("%3.5f : ", t_f);
#endif
led_doshutter(flasher, (int)(t_f * LB_SHUTTER));
return(1);
}
int
led_init(void)
{
consolefd = open("/dev/tty0", O_RDONLY);
if (consolefd == -1)
return(0);
return(1);
}
void
led_uninit(void)
{
close(consolefd);
return;
}
void
led_set(void)
{
char led;
ioctl(consolefd, KDSETLED, 1);
return;
}
void
led_unset(void)
{
char led;
ioctl(consolefd, KDSETLED, 0);
return;
}
int
led_change(void)
{
char led;
if (ioctl(consolefd, KDGETLED, &led) != -1) {
ioctl(consolefd, KDSETLED, (led == 1) ? 0 : 1);
}
return(led);
}
@HWA
08.0 Building a packet sniffer from the ground up Part I
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Basic Packet-Sniffer Construction
from the Ground Up
Part 1
by
Chad Renfro
raw_sock@hotmail.com
Packet sniffers are applications used by network administrators to monitor and
validate network traffic. Sniffers are programs used to read packets that travel across
the network at various levels of the OSI layer. And like most security tools sniffers too
can be used for both good and destructive purposes. On the light-side of network
administration sniffers help quickly track down problems such as bottlenecks and
misplaced filters. However on the dark-side sniffers can be used to reap tremendous
amounts of havoc by gathering legitimate user names and passwords so that other
machines can be quickly compromised. Hopefully this paper will be used to help
administrators gain control of their networks by being able to analyze network traffic
not only by using preconstructed sniffers but by being able to create their own. This
paper will look at the packet sniffer from the bottem up, looking in depth at the sniffer
core and then gradualy adding functionality to the application. The example included
here will help illustrate some rather cumbersome issues when dealing with network
programing. In no way will this single paper teach a person to write a complete sniffing
application like tcpdump or sniffit. It will however teach some very fundamental issues
that are inherent to all packet sniffers. Like how the packets are accessed on the network
and how to work with the packets at different layers.
The most basic sniffer...
Sniffer #1.
This sniffer will illustrate the use of the SOCK_RAW device and show how to gather
packets from the network and print out some simple header information to std_out.
Although the basic premise is that packet sniffers operate in a promiscuous mode which
listens to all packets weather or not the packet is destined for the machines mac address,
this example will collect packets in a non-promiscuous mode . This will let usconcentrate
on the SOCK_RAW device for the first example. To operate this same code in a
promiscous mode the network card may be put in a promiscous mode manually. To do
this type this in after the log in :
> su -
Password : ********
# ifconfig eth0 promisc
This will now set the network interface eth0 in promiscous mode.
/************************simple_Tcp_sniff.c********************/
1. #include
2. #include
3. #include
4. #include
5. #include "headers.h"
6. int main()
7. {
8. int sock, bytes_recieved, fromlen;
9. char buffer[65535];
10. struct sockaddr_in from;
11. struct ip *ip;
12. struct tcp *tcp;
13.
14. sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
15. while(1)
16. {
17. fromlen = sizeof from;
18. bytes_recieved = recvfrom(sock, buffer, sizeof buffer, 0,
(struct sockaddr *)&from, &fromlen);
19. printf("\nBytes received ::: %5d\n",bytes_recieved);
20. printf("Source address ::: %s\n",inet_ntoa(from.sin_addr));
21. ip = (struct ip *)buffer;
22. printf("IP header length ::: %d\n",ip->ip_length);
23. printf("Protocol ::: %d\n",ip->ip_protocol);
24. tcp = (struct tcp *)(buffer + (4*ip->ip_length));
25. printf("Source port ::: %d\n",ntohs(tcp->tcp_source_port);
26. printf("Dest port ::: %d\n",ntohs(tcp->tcp_dest_port));
27. }
28. }
/***********************EOF**********************************/
What this means :
Line 1-4 :
These are the header files required to use some needed c functions we will use later
= functions like printf and std_out
= this will give access to the SOCK_RAW and the
IPPROTO_TCP defines
= structs like the sockaddr_in
= lets us use the functions to do network to host byte
order conversions
line 5 :
This is the header file headers.h that is also included with this program to give standard
structures to access the ip and tcp fields. The structures identify each field in the ip and
tcp header for instance :
struct ip {
unsigned int ip_length:4; /* length of ip-header in 32-bit
words*/
unsigned int ip_version:4; /* set to "4", for Ipv4 */
unsigned char ip_tos; /* type of service*/
unsigned short ip_total_length; /* Total length of ip datagram in
bytes */
unsigned short ip_id; /*identification field*/
unsigned short ip_flags;
unsigned char ip_ttl; /*time-to-live, sets upper limit
for max number of routers to
go through before the packet is
discarded*/
unsigned char ip_protocol; /*identifies the correct transport
protocol */
unsigned short ip_cksum; /*calculated for the ip header ONLY*/
unsigned int ip_source; /*source ip */
unsigned int ip_dest; /*dest ip*/
};
struct tcp {
unsigned short tcp_source_port; /*tcp source port*/
unsigned short tcp_dest_port; /*tcp dest port*/
unsigned int tcp_seqno; /*tcp sequence number,
identifies the byte in the
stream of data*/
unsigned int tcp_ackno; /*contains the next seq num that
the sender expects to recieve*/
unsigned int tcp_res1:4, /*little-endian*/
tcp_hlen:4, /*length of tcp header in 32-bit
words*/
tcp_fin:1, /*Finish flag "fin"*/
tcp_syn:1, /*Synchronize sequence
numbers to start a connection
tcp_rst:1, /*Reset flag */
tcp_psh:1, /*Push, sends data to the
application*/
tcp_ack:1, /*acknowledge*/
tcp_urg:1, /*urgent pointer*/
tcp_res2:2;
unsigned short tcp_winsize; /*maxinum number of bytes able
to recieve*/
unsigned short tcp_cksum; /*checksum to cover the tcp
header and data portion of the
packet*/
unsigned short tcp_urgent; /*vaild only if the urgent flag is
set, used to transmit
emergency data */
};
line 8-13 :
This is the variable declaration section
integers :
sock = socket file descriptor
bytes_recieved = bytes read from the open socket "sock"
fromlen = the size of the from structure char :
buffer = where the ip packet that is read off the
wire will be held buffer will hold a datagram
of 65535 bytes which is the maximum length
of an ip datagram.
Struct sockaddr_in :
struct sockaddr_in {
short int sin_family; /* Address family */
unsigned short int sin_port; /* Port number */
struct in_addr sin_addr; /* Internet address */
unsigned char sin_zero[8]; /* Same size as struct sockaddr */
};
Before we go any further two topics should be covered,byte-ordering and sockaddr
structures. Byte-ordering,is the way that the operating system stores bytes in memory.
There are two ways that this is done first with the low-order byte at the starting address
this is known as "little-endian" or host-byte order. Next bytes can be stored with the
high order byte at the starting address, this is called "big-endian" or network byte order.
The Internet protocol uses >>>>>> network byte order.
This is important because if you are working on an intel based linux box you will be
programming on a little-endian machine and to send data via ip you must convert the
bytes to network-byte order. For examle lets say we are going to store a 2-byte number
in memory say the value is (in hex) 0x0203
First this is how the value is stored on a big-endian machine:
___________
| 02 | 03 |
|_____|_____|
address: 0 1
And here is the same value on a little-endian machine:
___________
|03 | 02 |
|_____|_____|
address: 1 0
The same value is being represented in both examples it is just how we order the bytes
that changes.
The next topic that you must understand is the sockaddr vs. the sockaddr_in structures.
The struct sockaddr is used to hold information about the socket such as the family type
and other address information it looks like :
struct sockaddr {
unsigned short sa_family; /*address family*/
char sa_data[14]; /*address data*/
};
The first element in the structure "sa_family" will be used to reference what the family
type is for the socket, in our sniffer it will be AF_INET. Next the "sa_data" element
holds the destination port and address for the socket. To make it easier to deal with the
sockaddr struct the use of the sockaddr_in structure is commonly used. Sockaddr_in
makes it easier to reference all of the elements that are contained by sockaddr.
Sockaddr_in looks like:
struct sockaddr_in {
short int sin_family; /* Address family */
unsigned short int sin_port; /* Port number */
struct in_addr sin_addr; /* Internet address */
unsigned char sin_zero[8]; /* Same size as struct sockaddr */
};
We will use this struct and declare a variable "from" which will give us the information
on the packet that we will collect from the raw socket. For instance the var
"from.sin_addr" will give access to the packets source address (in
network byte order). The thing to mention here is that all items in the sockaddr_in
structure must be in network-byte order. When we receive the data in the sockaddr_in
struct we must then convert it back to Host-byte order. To do this we can use some
predefined functions to convert back and forth between host and network byteorder.
Here are the functions we will use:
ntohs : this function converts network byte order to host byte order
for a 16-bit short
ntohl : same as above but for a 32-bit long
inet_ntoa : this function converts a 32-bit network binary value to a
dotted decimal ip address
inet_aton : converts a character string address to the 32-bit network
binary value
inet_addr : takes a char string dotted decimal addr and returns a 32-bit
network binary value
To further illustrate ,say I want to know the port number that this packet originated from:
int packet_port; packet_port =ntohs(from.sin_port);
^^^^^
If I want the source IP address of the packet we will use a special function to get it to the
123.123.123.123 format:
char *ip_addr; ip_addr =inet_ntoa(from.sin_addr)
^^^^^^^^^
line 11-12:
struct ip *ip :
struct tcp *tcp :
This is a structure that we defined in our header file "headers.h". This structure is
declared so that we can access individual fields of the ip/tcp header. The structure is like
a transparent slide with predefined fields drawn on it. When a packet is taken off
the wire it is a stream of bits, to make sense of it the "transparency" (or cast) is laid on
top of or over the bits so the individual fields can be referenced.
Line 14 :
sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
This is the most important line in the entire program. Socket() takes three arguments in
this form:
sockfd = socket(int family, int type, int protocol);
The first argument is the family. This could be either AF_UNIX which is used so a process
can communicate with another process on the same host or AF_INET which is used for
internet communication between remote hosts. In this case it will be AF_INET . Next
is the type, the type is usually between 1 of 4 choices (there are others that we will not
discuss here) the main four are :
1. SOCK_DRAM : used for udp datagrams
2. SOCK_STREAM : used for tcp packets
3. SOCK_RAW : used to bypass the transport layer
and directly access the IP layer
4. SOCK_PACKET : this is linux specific, it is similuar to
SOCK_RAW except it accesses the DATA LINK Layer
For our needs we will use the SOCK_RAW type. You must have root acces to open a
raw socket. The last parameter is the protocol,the protocol value specifies what type of
traffic the socket should receive , for normal sockets this value is usally set to "0"
because the socket can figure out if for instance the "type" of SOCK_DGRAM is
specified then the protocol should be UDP.In our case we just want to look at tcp
traffic so we will specify IPPROTO_TCP.
line 15 :
while (1)
The while (1) puts the program into an infinite loop this is necessary so that after the
first packet is processed we will loop around and grab the next.
Line 18:
bytes_recieved = recvfrom(sock, buffer, sizeof buffer, 0, (struct sockaddr *)&from, &fromlen);
Now here is where we are actually reading data from the open socket "sock".The from
struct is also filled in but notice that we are casting "from" from a "sockaddr_in" struct
to a "sockaddr" struct. We do this because the recvfrom() requires a sockaddr type but
to access the separate fields we will continue to use the sockaddr_in structure. The
length of the "from" struct must also be present and passed by address. The recvfrom()
call will return the number of bytes on success and a -1 on error and fill the global var
errno.
This is what we call "blocking-I/O" the recvfrom() will wait here forever until a
datagram on the open socket is ready to be processed. This is opposed to
Non-blocking I/O which is like running a process in the background and move on to
other tasks.
Line 20:
printf("Source address ::: %s\n",inet_ntoa(from.sin_addr));
This printf uses the special function inet_ntoa() to take the value of "from.sin_addr"
which is stored in Network-byte order and outputs a value in a readable ip form such
as 192.168.1.XXX.
Line 21:
ip = (struct ip *)buffer;
This is where we will overlay a predefined structure that will help us to individually
identify the fields in the packet that we pick up from the open socket.
Line 22:
printf("IP header length ::: %d\n",ip->ip_length);
The thing to notice on this line is the "ip->ip_length" this will access a pointer in
memory to the ip header length the important thing to remember is that the length
will be represented in 4-byte words this will be more important later when trying to
access items past the ip header such as the tcp header or the data portion of the packet.
Line 23:
printf("Protocol ::: %d\n",ip->ip_protocol);
This gives access to the type of protocol such as 6 for tcp or 17 for udp.
Line 24:
tcp = (struct tcp *)(buffer + (4*ip->ip_length));
Remember earlier it was mentioned that the ip header length is stored in 4 byte words,
this is where that bit of information becomes important. Here we are trying to get access
to the tcp header fields, to do this we must overlay a structure that has the fields
predefined just as we did with ip. There is one key difference here the ip header fields
were easy to access due to the fact that the beginning of the buffer was also the beginning
of the ip header as so :
|----------------- buffer ----------------|
_________________________________________
| ip header | |
|____________________|____________________|
^
*ip
^
*buffer
So to get access to the ip header we just set a pointer casted as an ip structure to the
beginning of the buffer like "ip = (struct ip *)buffer;". To get access to the tcp header
is a little more difficult due to the fact that we must set a pointer and cast it as a tcp
structure at the beginning of the tcp header which follows the ip header in the buffer
as so :
|----------------- buffer ---------------|
________________________________________
| ip header | tcp header | |
|___________|____________|_______________|
^
*tcp
This is why we use 4*ip->ip_length to find the start of the tcp header.
Line 25-26:
printf("Source port ::: %d\n",ntohs(tcp->tcp_source_port);
printf("Dest port ::: %d\n",ntohs(tcp->tcp_dest_port));
We can now access the source and dest ports which are located in the tcp header via
the structure as defined above.
This will conclude our first very simple tcp sniffer. This was a very basic application
that should help define how to access packets passing on the network and how to use
sockets to access the packets. Hopefully this will be the first of many papers to come,
which each proceeding paper we will add a new or more complex feature to the sniffer. I
should also mention that there a number of great resources on the net that should aid you
in further research in this area :
1. Beej's Guide to Network Programming
This is an awesome paper that really helps
clear up any misconceptions about network programming.
[http://www.ecst.csuchico.edu/~beej/guide/net]
2. TCP/IP Illustrated Vol 1,2,3
W.Richard Stevens
To use the above program, cut out the above code and strip off all
of the line numbers. Save the edited file as sniff.c. Next cut
out the header file headers.h (below) and save it to a file headers.h
in the same directory. Now just compile: gcc -o sniff sniff.c
You should now have the executable "sniff", to run it type
#./sniff
/*************************headers.h**************************/
/*structure of an ip header */
struct ip {
unsigned int ip_length:4; /*little-endian*/
unsigned int ip_version:4;
unsigned char ip_tos;
unsigned short ip_total_length;
unsigned short ip_id;
unsigned short ip_flags;
unsigned char ip_ttl;
unsigned char ip_protocol;
unsigned short ip_cksum;
unsigned int ip_source;
unsigned int ip_dest;
};
/* Structure of a TCP header */
struct tcp {
unsigned short tcp_source_port;
unsigned short tcp_dest_port;
unsigned int tcp_seqno;
unsigned int tcp_ackno;
unsigned int tcp_res1:4, /*little-endian*/
tcp_hlen:4,
tcp_fin:1,
tcp_syn:1,
tcp_rst:1,
tcp_psh:1,
tcp_ack:1,
tcp_urg:1,
tcp_res2:2;
unsigned short tcp_winsize;
unsigned short tcp_cksum;
unsigned short tcp_urgent;
};
/*********************EOF***********************************/
*
@HWA
09.0 CIAC Security advisory on HP-UX ftp,hpterm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Missed this is last issue, go figure I was having a month....
Date: Wed, 31 Mar 1999 11:30:48 -0800 (PST)
From: CIAC Mail User
To: ciac-bulletin@rumpole.llnl.gov
Subject: CIAC Bulletin J-038: HP-UX Vulnerabilities (hpterm, ftp)
[ For Public Release ]
-----BEGIN PGP SIGNED MESSAGE-----
__________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
INFORMATION BULLETIN
HP-UX Vulnerabilities (hpterm, ftp)
H-P Security Bulletins #00093 and #00094
March 31, 1999 15:00 GMT Number J-038
______________________________________________________________________________
PROBLEM: Two vulnerabilities have been identified by Hewlett-Packard
Company.
1) PHSS_13560 introduced a library access problem into hpterm.
2) There is a Security Vulnerability during ftp operations.
PLATFORM: 1) HP9000 Series 700 and Series 800, HP-UX release 10.20 only.
2) HP9000 Series 7/800 running HP-UX release 11.00 only.
DAMAGE: Users can gain increased privileges.
SOLUTION: Apply patches.
______________________________________________________________________________
VULNERABILITY Risk is high. Both of these vulnerabilities affect systems
ASSESSMENT: security. Patches should be applied as soon as possible.
______________________________________________________________________________
[Start Hewlett-Packard Company Advisory]
1) PHSS_13560
Document ID: HPSBUX9903-093
Date Loaded: 19990317
Title: Security Vulnerability with hpterm on HP-UX 10.20
- -----------------------------------------------------------------------
HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #00093, 18 March 1999
- -----------------------------------------------------------------------
The information in the following Security Bulletin should be acted upon
as soon as possible. Hewlett-Packard Company will not be liable for any
consequences to any customer resulting from customer's failure to fully
implement instructions in this Security Bulletin as soon as possible.
- -----------------------------------------------------------------------
PROBLEM: PHSS_13560 introduced a library access problem into hpterm.
PLATFORM: HP9000 Series 700 and Series 800, HP-UX release 10.20 only.
DAMAGE: Users can gain increased privileges.
SOLUTION: Install PHSS_17830.
AVAILABILITY: The patch is available now.
- -----------------------------------------------------------------------
I.
A. Background
PHSS_13560 introduced a library access problem into hpterm, the
terminal emulator for the X Window system. (See hpterm(1)).
B. Fixing the problem
Installing patch PHSS_17830 completely fixes this problem.
NOTE: Three older hpterm patches have been released including
PHSS_13560, PHSS_15431, and PHSS_17332. All of these older
patches are being superseded with the release of the
PHSS_17830.
Do not use PHSS_13560, PHSS_15431, or PHSS_17332.
C. To subscribe to automatically receive future NEW HP Security
Bulletins from the HP Electronic Support Center via electronic
mail, do the following:
Use your browser to get to the HP Electronic Support Center page
at:
http://us-support.external.hp.com
(for US, Canada, Asia-Pacific, & Latin-America)
http://europe-support.external.hp.com (for Europe)
Login with your user ID and password (or register for one).
Remember to save the User ID assigned to you, and your password.
Once you are in the Main Menu:
To -subscribe- to future HP Security Bulletins,
click on "Support Information Digests".
To -review- bulletins already released from the main Menu,
click on the "Technical Knowledge Database (Security Bulletins
only)".
Near the bottom of the next page, click on "Browse the HP Security
Bulletin Archive".
Once in the archive there is another link to our current Security
Patch Matrix. Updated daily, this matrix categorizes security
patches by platform/OS release, and by bulletin topic.
The security patch matrix is also available via anonymous ftp:
us-ffs.external.hp.com
~ftp/export/patches/hp-ux_patch_matrix
D. To report new security vulnerabilities, send email to
security-alert@hp.com
Please encrypt any exploit information using the security-alert
PGP key, available from your local key server, or by sending a
message with a -subject- (not body) of 'get key' (no quotes) to
security-alert@hp.com.
Permission is granted for copying and circulating this Bulletin to
Hewlett-Packard (HP) customers (or the Internet community) for the
purpose of alerting them to problems, if and only if, the Bulletin
is not edited or changed in any way, is attributed to HP, and
provided such reproduction and/or distribution is performed for
non-commercial purposes.
Any other use of this information is prohibited. HP is not liable
for any misuse of this information by any third party.
_____________________________________________________________________
- ---End of Document ID: HPSBUX9903-093---------------------------------
2) ftp
Document ID: HPSBUX9903-094
Date Loaded: 19990323
Title: Security Vulnerability with ftp on HP-UX 11.00
- -----------------------------------------------------------------------
HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #00094, 24 March 1999
- -----------------------------------------------------------------------
The information in the following Security Bulletin should be acted upon
as soon as possible. Hewlett-Packard Company will not be liable for any
consequences to any customer resulting from customer's failure to fully
implement instructions in this Security Bulletin as soon as possible.
- -----------------------------------------------------------------------
PROBLEM: Security Vulnerability during ftp operations.
PLATFORM: HP9000 Series 7/800 running HP-UX release 11.00 only.
DAMAGE: Users can increase privileges
SOLUTION: Apply the patch specified below
AVAILABILITY: The patch is available now.
- -----------------------------------------------------------------------
I.
A. Background
Hewlett-Packard Company has found that during normal operations,
the ftp program might grant users increased privileges.
B. Fixing the problem
Obtaining and installing the following patch will completely close
this vulnerability. Rebooting the system will NOT be required.
For all HP9000 S7/800 platforms running HP-UX 11.00: PHCO_17601
C. To subscribe to automatically receive future NEW HP Security
Bulletins or access the HP Electronic Support Center, use your
browser to get to our ESC web page at:
http://us-support.external.hp.com (for non-European locations),
or http://europe-support.external.hp.com (for Europe)
Login with your user ID and password (or register for one).
Remember to save the User ID/password assigned to you.
Once you are in the Main Menu:
To -subscribe- to future HP Security Bulletins,
click on "Support Information Digests".
To -review Security bulletins already released-,
click on the "Search Technical Knowledge Database."
To -retrieve patches-, click on "Individual Patches" and select
appropriate release and locate with the patch identifier (ID).
To -browse the HP Security Bulletin Archive-, select the link at
the bottom of the page once in the "Support Information Digests".
To -view the Security Patch Matrix-, (updated daily) which
categorizes security patches by platform/OS release, and by
bulletin topic, go to the archive (above) and follow the links.
The security patch matrix is also available via anonymous ftp:
us-ffs.external.hp.com or ~ftp/export/patches/hp-ux_patch_matrix
D. To report new security vulnerabilities, send email to
security-alert@hp.com
Please encrypt any exploit information using the security-alert
PGP key, available from your local key server, or by sending a
message with a -subject- (not body) of 'get key' (no quotes) to
security-alert@hp.com.
Permission is granted for copying and circulating this Bulletin to
Hewlett-Packard (HP) customers (or the Internet community) for the
purpose of alerting them to problems, if and only if, the Bulletin
is not edited or changed in any way, is attributed to HP, and
provided such reproduction and/or distribution is performed for
non-commercial purposes.
Any other use of this information is prohibited. HP is not liable
for any misuse of this information by any third party.
______________________________________________________________________
- ---End of Document ID: HPSBUX9903-094---------------------------------
[End Hewlett-Packard Company Advisory]
___________________________________________________________________________
CIAC wishes to acknowledge the contributions of Hewlett-Packard Company for
the information contained in this bulletin.
___________________________________________________________________________
CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.
CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
Voice: +1 925-422-8193
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@llnl.gov
For emergencies and off-hour assistance, DOE, DOE contractor sites,
and the NIH may contact CIAC 24-hours a day. During off hours (5PM -
8AM PST), call the CIAC voice number 925-422-8193 and leave a message,
or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two
Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC
duty person, and the secondary PIN number, 8550074 is for the CIAC
Project Leader.
Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.
World Wide Web: http://www.ciac.org/
(or http://ciac.llnl.gov -- they're the same machine)
Anonymous FTP: ftp.ciac.org
(or ciac.llnl.gov -- they're the same machine)
Modem access: +1 (925) 423-4753 (28.8K baud)
+1 (925) 423-3331 (28.8K baud)
CIAC has several self-subscribing mailing lists for electronic
publications:
1. CIAC-BULLETIN for Advisories, highest priority - time critical
information and Bulletins, important computer security information;
2. SPI-ANNOUNCE for official news about Security Profile Inspector
(SPI) software updates, new features, distribution and
availability;
3. SPI-NOTES, for discussion of problems and solutions regarding the
use of SPI products.
Our mailing lists are managed by a public domain software package
called Majordomo, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send the
following request as the E-mail message body, substituting
ciac-bulletin, spi-announce OR spi-notes for list-name:
E-mail to ciac-listproc@llnl.gov or majordomo@tholia.llnl.gov:
subscribe list-name
e.g., subscribe ciac-bulletin
You will receive an acknowledgment email immediately with a confirmation
that you will need to mail back to the addresses above, as per the
instructions in the email. This is a partial protection to make sure
you are really the one who asked to be signed up for the list in question.
If you include the word 'help' in the body of an email to the above address,
it will also send back an information file on how to subscribe/unsubscribe,
get past issues of CIAC bulletins via email, etc.
PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins. If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.
This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.
LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)
J-027: Digital Unix Vulnerabilities ( at , inc )
J-028: Sun Solaris Vulnerabilities (sdtcm_convert, man/catman, CDE)
J-029: Buffer Overflows in Various FTP Servers
J-030: Microsoft BackOffice Vulnerability
J-031: Debian Linux "Super" package Buffer Overflow
J-032: Windows Backdoors Update II:
J-034: Cisco 7xx TCP and HTTP Vulnerabilities
J-035: Linux Blind TCP Spoofing
J-036: LDAP Buffer overflow against Microsoft Directory Services
J-037: W97M.Melissa Word Macro Virus
-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
iQCVAwUBNwJkHLnzJzdsy3QZAQHrWAP9E27Nc3P8XLWJ1IM/JOzMdHy5mvymnUdh
dzkEuldX35r+KGPlZYGxAq6NbKeYQFgi24C1OHg7V/MhcgnXKHPB6DN7Zdd6g6ii
sUAnZ7LD3MqQb7OIMq2D3GdWzLzn/u5qpanKt1VjNYtQCGi4RbH9YgJFnLFgma8I
dX/jer4bE6M=
=Q2lE
-----END PGP SIGNATU