595 lines
26 KiB
Text
595 lines
26 KiB
Text
.oO Phrack 50 Oo.
|
|
|
|
Volume Seven, Issue Fifty
|
|
|
|
3 of 16
|
|
|
|
|
|
// // /\ // ====
|
|
// // //\\ // ====
|
|
==== // // \\/ ====
|
|
|
|
/\ // // \\ // /=== ====
|
|
//\\ // // // // \=\ ====
|
|
// \\/ \\ // // ===/ ====
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
----<>----
|
|
|
|
|
|
=--=--=--=--=--=--=--=
|
|
Portable BBS Hacking
|
|
by: Khelbin
|
|
=--=--=--=--=--=--=--=
|
|
|
|
|
|
This hack basically has little to do with the BBS software itself but
|
|
with the archiver which is being used. I've used this technique on a
|
|
mock Renegade setup and with pkzip/pkunzip as the archiver. I'm sure
|
|
that this same type of technique will be successful on many other BBS
|
|
platforms and with other archivers as well. While explaining this, I will
|
|
use Renegade and pkzip/pkunzip as my example.
|
|
|
|
A Renegade setup is most likely vulnerable if it will pkunzip any user
|
|
supplied zipfile. This is because Renegade's default command to unzip files
|
|
is "pkunzip -do <filename>". The -d flag unzips the file retaining any
|
|
directories which were included into the zip file and the -o flag will
|
|
automatically overwrite any file.
|
|
|
|
Suppose the remote system is also setup in a normal Renegade fashion.
|
|
Let's use this file tree as an example:
|
|
|
|
C:\RENEGADE\
|
|
C:\RENEGADE\TEMP\
|
|
C:\RENEGADE\DATA\
|
|
|
|
The other subdirectories are unimportant for our discussion. Suppose
|
|
that C:\TEMP is where our uploaded file will go for it to be unzipped and
|
|
then scanned for viruses. C:\RENEGADE\DATA\ is where the USERS.DAT file
|
|
is stored, containing all the users login information.
|
|
|
|
Wouldn't it be nice if we could put our own USERS.DAT in there instead?
|
|
To do this, you must first generate a USERS.DAT file. This is easy enough.
|
|
Just download a copy of Renegade which is the same version as the target
|
|
machine and then use the user editor to make a "SYSOP" account with the
|
|
password "SYSOP" (this should be the default anyway on the USERS.DAT file).
|
|
|
|
Here's how we prepare the zipfile on our own machine:
|
|
|
|
C:\>md tmp
|
|
C:\>md c:\tmp\ddsdata
|
|
C:\>copy c:\renegade\data\users.dat c:\tmp\ddsdata
|
|
C:\>cd tmp
|
|
C:\TMP>pkzip -pr evil.zip
|
|
|
|
Now we get out our trusty hex editor and edit evil.zip. Change every
|
|
occurrence of "ddsdata" in evil.zip to read "../data" and make sure that the
|
|
slash is a forward-slash and not a back-slash. Now when you upload
|
|
evil.zip to this particular BBS, it will expand to "../data/users.dat"
|
|
and your USERS.DAT file will overwrite their USERS.DAT file since the -od
|
|
flag is default on Renegade.
|
|
|
|
Now you can login as SYSOP with a password SYSOP and do as you please.
|
|
You could also overwrite virtually any file on a BBS like this and believe
|
|
me, many do have this vulnerability or something very close to it. You are
|
|
only limited in how much you can traverse up and down directories by DOS's
|
|
maximum file length of 12 (8 plus "." plus 3 = 12). I quickly tried
|
|
inserting a few blocks into the zipfile in order to produce a limitless
|
|
amount of traversing which but it seemed to corrupt the file for some
|
|
reason.
|
|
|
|
Removing the -o flag is not a fix for this bug. Without the -o flag,
|
|
you can "hang" the system in a denial of service attack. By again hex
|
|
editing the names of the files within your evil.zip, you can make it have
|
|
two files with the same name. When it tries to unzip the second file, it
|
|
will prompt locally whether to overwrite the file or not and "hang" the
|
|
board. Instead, the -d flag is what should be removed.
|
|
|
|
This is just an example as I'm sure many other BBS systems do this same
|
|
type of uncompressing. I'd also bet that arj, lha, and several others, can
|
|
also be hex edited and yield similar results. Either way, it's either take
|
|
out the "restore/create directories within archive" option or pay the price.
|
|
|
|
|
|
----<>----
|
|
|
|
|
|
German Hacker "Luzifer" convicted by SevenUp / sec@sec.de
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
SYNOPSIS
|
|
========
|
|
On February 5th, 1997, Wilfried Hafner aka "Luzifer" was sentenced to
|
|
three years incarceration - no parole, no probation. I've got the story
|
|
for you right from the courtroom in Munich, Germany. This is one of the
|
|
first ever cases in which a hacker in Germany actually gets convicted, so
|
|
it's particularly interesting. (Although the court and I use the term
|
|
"hacking", this is actually a case of unethical electronic fraud.)
|
|
|
|
|
|
LUZIFER
|
|
=======
|
|
Wilfried Hafner (Luzifer) was born on April 6, 1972, in Breschau Italy.
|
|
According to his own circulum vitae, which he quoted in court himself,
|
|
he's been a pretty smart guy: He started programming at 8 years,and cracked
|
|
about 600 Commodore programs, at 14, got a modem and then started a BBS.
|
|
In 1990 he was blueboxing to some overseas partylines to communicate with
|
|
others. But he didn't seem to use any other "elite" chat systems like x.25
|
|
or IRC, so most people (including myself) didn't know him that well. In
|
|
1992 he moved to South Germany to goto school.
|
|
|
|
|
|
WHAT HE DID
|
|
===========
|
|
Luzifer set up some overseas partylines in the Dominican Republic,
|
|
Indonesia, The Philippines, and Israel. Some lines included live chat,
|
|
but most were just sex recordings. Then he used a local company PBX (a
|
|
Siemens Hicom 200 model), from his homeline, which was only "protected"
|
|
by a one digit code, to dialout to his partylines and his girlfriend in
|
|
Chile. He also was blueboxing (which the prosecution calls "C5-hacking")
|
|
from five lines simultaneously, mostly via China. To trick the partyline
|
|
provider and overseas telcos (who are aware of computer-generated calls)
|
|
he wrote a little program that would randomize aspects of the calls
|
|
(different calling intervals and different durations for the calls).
|
|
|
|
He got arrested the first time on 03/29/95, but was released again after
|
|
13 days. Unfortunately he restarted the phreaking right away. If he'd
|
|
had stopped then, he would just have gotten 1 year probation. However, he
|
|
was arrested again in January 1996, and has been in prison since.
|
|
|
|
Here are some numbers (shouts to Harper(tm)'s Index):
|
|
- Number of logged single phone connections: 18393
|
|
- Profit he makes for 1 min. partyline calls: US$ 0.35 - 0.50
|
|
- Total Damage (= lost profit of telco): US$ 1.15 Million
|
|
- Money that Luzifer got from the partylines: US$ 254,000
|
|
- Paragraph in German Law that covers this fraud: 263a StG
|
|
- Duration of all calls, if made sequentially: 140 days
|
|
|
|
|
|
THE TRIAL
|
|
=========
|
|
This trial was far less spectacular than OJ's. While 7 days had been
|
|
scheduled, the trial was over after the second day. The first day went
|
|
quite quick: The court didn't have enough judges available (two were present,
|
|
but three required), so it had to be postponed after some minutes.
|
|
|
|
At the second day, both, the prosecution and Luzifers two lawyers, made
|
|
a deal and plead guilty for three years prison (but no financial punitive).
|
|
In Germany, all sentences over two years cannot be carried out on probation.
|
|
But he has been allowed the use of a notebook computer. Rumor has it that
|
|
he might be get an "open" execution, meaning that he has to sleep in the
|
|
prison at night, but can work or study during the day.
|
|
|
|
The deal looked like the prosecution dropped all counts (including
|
|
the one abusing the PBX in the first place) but two: one for the blueboxing
|
|
before getting arrested, and one count for blueboxing afterwards. They don't
|
|
treat all 18393 connections as a separate count, but just each start of the
|
|
"auto-call-program".
|
|
|
|
|
|
QUOTES
|
|
======
|
|
Here are some interesting and funny quotes from the trial:
|
|
"Just for fun and technical curiosity" - Defendant
|
|
"Wouldn't one line be enough for technical experience"? - Judge
|
|
"I ordered 21 lines, but just got 5" - Defendant
|
|
"Lots of criminal energy" - Prosecutor
|
|
"He's obsessed and primarily competing with other hackers" - Lawyer
|
|
"A generation of run down computer kids" - Prosecutor
|
|
"He may keep the touchtone dialer, but we cannot return his laser fax,
|
|
because the company's PBX number is stored in its speedial" - Prosecutor
|
|
"Myself and the Telekom have learned a lot" - Prosecutor
|
|
"New cables must be installed, new satelites have to be shot into the air"
|
|
- Prosecutor about the consequences of used up trunks and intl. lines
|
|
"The German Telekom is distributing pornography with big profits" - Lawyer
|
|
|
|
|
|
----<>----
|
|
|
|
|
|
Yet another Lin(s)ux bug!
|
|
By: Xarthon
|
|
|
|
IP_MASQ is a commonly used new method of traffic forwarding which
|
|
may be enabled in newer Linux kernel versions. I have been doing some
|
|
research into this new feature.
|
|
|
|
IP_MASQ fails to check to make sure that a packet is in the non
|
|
routable range. If you are able to get any packet to its destination, the
|
|
header of that packet is rewritten.
|
|
|
|
Because of the lack of non-routable ip checking, the same tactics
|
|
that would be used a gateway machine, may also be used on a machine that
|
|
uses ip_masq.
|
|
|
|
So in conclusion, you are able to spoof as if you are on the
|
|
inside network, from the outside. But hey, what can you expect from
|
|
Linux?
|
|
|
|
|
|
----<>----
|
|
|
|
11.22.96
|
|
|
|
daemon9 and w0zz's adventure into warez-pup land...
|
|
|
|
|
|
|
|
*W|ZaRD* u there?
|
|
-> *W|ZaRD* yes?
|
|
<w0zz> d9
|
|
<d9> hi w0zz
|
|
*W|ZaRD* r u the prez of BREED?
|
|
*** |COBRA| invites you to channel #supreme
|
|
<d9> I am hungry
|
|
-> *W|ZaRD* yup
|
|
*_e|f_* hi there - you got a minute?
|
|
*W|ZaRD* alright.. i got a question for u...
|
|
*** d9 (plugHead@onyx.infonexus.com) has joined channel #supreme
|
|
*** Topic for #supreme: [SpR] Still in discussion phase! [SpR]
|
|
*** #supreme _e|f_ 848703589
|
|
*** Users on #supreme: d9 @{Imagine} @BL|ZZaRD @W|ZaRD @|COBRA| @_e|f_
|
|
<_e|f_> re d9
|
|
*** Mode change "+o d9" on channel #supreme by _e|f_
|
|
<|COBRA|> today is going to be a bad day :(
|
|
*W|ZaRD* would you be interested in merging with like 4-6 other groups to become 1 group.??
|
|
*W|ZaRD* i mean. all the other groups have like 11 sitez and 8-10 suppliers like NGP
|
|
*W|ZaRD* and if we merge we could be up there with Prestige, and Razor
|
|
<_e|f_:#supreme> hello d9
|
|
<d9> *W|ZaRD* i mean. all the other groups have like 11 sitez and 8-10 suppliers like NGP
|
|
-> *W|ZaRD* hmm
|
|
*** Inviting w0zz to channel #supreme
|
|
<_e|f_> we got a discussion going on here for big plans for a lot of us "smaller" groups (smaller as
|
|
compared to razor, prestige etc) :)
|
|
<d9> ah
|
|
*** Mystic12 (NONE@wheat-53.nb.net) has joined channel #supreme
|
|
<_e|f_> this is all still in discussion stages
|
|
<w0zz:#!r00t> hahahaha
|
|
*** Mode change "+o Mystic12" on channel #supreme by W|ZaRD
|
|
<_e|f_:#supreme> but would you be interested in a joint venture between a few of us smaller release groups
|
|
to combine into one large release group - to challenge razor and prestige?
|
|
<d9> w0zz
|
|
<w0zz> you've been sucked into warez kiddie conspiracies
|
|
<d9> join me
|
|
<w0zz:#!r00t> where are you?
|
|
*** Inviting w0zz to channel #supreme
|
|
*** w0zz (wozz@big.wookie.net) has joined channel #supreme
|
|
<d9> well...
|
|
*** Mode change "+o w0zz" on channel #supreme by d9
|
|
<w0zz> werd
|
|
<_e|f_> re wozz
|
|
<d9> hi w0zz
|
|
<w0zz> hi there
|
|
<_e|f_> i can send u a log to flesh out a few more details if you like
|
|
<w0zz> i've got mackin' warez
|
|
<d9> hmm
|
|
<d9> sure
|
|
*w0zz* you recording this for line noise ?
|
|
*w0zz* ;)
|
|
-> *w0zz* indeed...;)
|
|
*w0zz* heh
|
|
<d9> the thing is, I have all this porn I want to unload...
|
|
<w0zz> yah, i got da mackin porn too
|
|
<d9> but, no good place to distro it...
|
|
*** ^DRiFTeR^ (~Drifter@203.30.237.48) has joined channel #supreme
|
|
*** Mode change "+o ^DRiFTeR^" on channel #supreme by _e|f_
|
|
<_e|f_> hey drifter
|
|
<d9> I was using this panix account, but all that SYN flooding stopped that cold...
|
|
<_e|f_> drifter is muh vp :)
|
|
<RAgent:#!r00t> do you even know what BREED is, route?
|
|
<d9> warez pups?
|
|
<_e|f_:#supreme> drifter: d9 and wozz are from breed
|
|
<_e|f_:#supreme> blizzard and wizard are from NGP
|
|
<^DRiFTeR^:#supreme> k
|
|
<d9:#!r00t> HAHAHAhahahaha
|
|
<Mystic12:#supreme> I am also from NGP
|
|
*** Signoff: Mystic12 (Leaving)
|
|
<W|ZaRD:#supreme> so is Mystic12
|
|
<RAgent:#!r00t> well, looks like it. just wondered if you knew them at all
|
|
<d9> w0zz... you get the new shit I send you?
|
|
*** Mystic12 (NONE@wheat-53.nb.net) has joined channel #supreme
|
|
<w0zz:#supreme> yah
|
|
<_e|f_:#supreme> sorry mystic - didnt see yew there
|
|
<d9:#!r00t> nope!
|
|
*** Mode change "+o Mystic12" on channel #supreme by W|ZaRD
|
|
<w0zz> indexed and everything
|
|
<RAgent:#!r00t> hahaha
|
|
<w0zz> i spanked my monkey for hours
|
|
<RAgent:#!r00t> whee
|
|
<d9> werd.
|
|
<d9:#!r00t> AAAAAHAHAHahahhahaha WOZZ!
|
|
<_e|f_> brb
|
|
<d9> hmm
|
|
#supreme Mystic12 H@ NONE@wheat-53.nb.net (CCINC)
|
|
#supreme ^DRiFTeR^ H@ ~Drifter@203.30.237.48 (ReaLMS oF Da NiTe - HrD)
|
|
#supreme w0zz H@ wozz@big.wookie.net (w0zz)
|
|
#supreme d9 H@ plugHead@onyx.infonexus.com (Built Demon Tough)
|
|
#supreme {Imagine} H@ BOB@199.190.110.99 (.:tORn f#E?h:. v1.45 by SLaG)
|
|
#supreme BL|ZZaRD H@ blizzard@ip222.tol.primenet.com (hehe)
|
|
#supreme W|ZaRD H@ m3ntal@ip201.tol.primenet.com (M3NTaL)
|
|
#supreme |COBRA| H@ cobra@slbri3p24.ozemail.com.au (100% ReVpOwEr)
|
|
#supreme _e|f_ H@ _e|f_@203.26.197.12 (blah)
|
|
<w0zz:#!r00t> werd
|
|
*** Mode change "-ooo _e|f_ |COBRA| W|ZaRD" on channel #supreme by d9
|
|
*** Mode change "-ooo BL|ZZaRD w0zz ^DRiFTeR^" on channel #supreme by d9
|
|
*** Mode change "-o Mystic12" on channel #supreme by d9
|
|
<W|ZaRD> hehe
|
|
*** Mode change "+o w0zz" on channel #supreme by d9
|
|
<_e|f_> sigh
|
|
<W|ZaRD> what would the new group name be.. if this happened?
|
|
<d9> the new name?
|
|
<W|ZaRD> hmm. nice takeover
|
|
<W|ZaRD> hehe
|
|
<w0zz> werd
|
|
<d9> w0zz, what do you think?
|
|
<W|ZaRD> new group name
|
|
<_e|f_> d9: ops plz
|
|
<d9> r00t? guild?
|
|
<d9> wait
|
|
<_e|f_> this is only a temp channel neway d9
|
|
<W|ZaRD> guild wuz already used
|
|
<d9> those are taken...
|
|
<_e|f_> so its a waste to do a takeover
|
|
<w0zz> i like r00t
|
|
<w0zz> oh
|
|
<w0zz> yeah
|
|
<w0zz> those guys are eleet
|
|
<d9> yah
|
|
<d9> I hear r00t has this 10 year old that can break into .mil sites...
|
|
*** d9 is now known as daemon9
|
|
<w0zz> duod, he's like D.A.R.Y.L.
|
|
<W|ZaRD> hehe
|
|
<daemon9> yah..
|
|
<_e|f_> d9: i take it by this yew aint interested?
|
|
<_e|f_> :\
|
|
<daemon9> anyway, bak to pr0n.
|
|
<W|ZaRD> anywayz.. op me d00d
|
|
<w0zz> me too
|
|
<w0zz> must have m0re pr0n
|
|
*** Mode change "+m" on channel #supreme by daemon9
|
|
<daemon9> yes
|
|
*** w0zz has left channel #supreme
|
|
<daemon9> more pr0n
|
|
<w0zz:#!r00t> werd
|
|
<w0zz:#!r00t> that rooled
|
|
<daemon9> mega-pr0n
|
|
<W|ZaRD> porn
|
|
<W|ZaRD> hehe
|
|
<daemon9> kiddie-pr0n
|
|
<W|ZaRD> op me plz
|
|
<daemon9> wizard, you are fine the way you are.
|
|
*** w0zz is now known as [w0zzz]
|
|
*** daemon9 has left channel #supreme
|
|
*** daemon9 is now known as r0ute
|
|
<r0ute> hahaha
|
|
<[w0zzz]> heh
|
|
<r0ute> that was fun.
|
|
<r0ute> good way to wake up from a nap
|
|
|
|
|
|
|
|
----<>----
|
|
|
|
|
|
|
|
Large Packet Attacks
|
|
(AKA Ping of Death)
|
|
---------------------------------
|
|
|
|
|
|
[ Introduction ]
|
|
|
|
Recently, the Internet has seen a large surge in denial of service
|
|
attacks. A denial of service attack in this case is simply an action of some
|
|
kind that prevents the normal functionality of the network. It denies service.
|
|
This trend began a few months back with TCP SYN flooding and continues with the
|
|
"large packet attack". In comparison with SYN flooding, the large packet attack
|
|
is a much more simple attack in both concept (explained below) and execution
|
|
(the attack can be carried out by anyone with access to a Windows 95 machine).
|
|
TCP SYN flooding is more complex in nature and does not exploit a flaw so much
|
|
as it exploits an implementation weakness.
|
|
The large packet attack is also much more devastating then TCP SYN
|
|
flooding. It can quite simply cause a machine to crash, whereas SYN flooding
|
|
may just deny access to mail or web services of a machine for the duration of
|
|
the attack. For more information on TCP SYN flooding see Phrack 49, article 13.
|
|
(NOTE: The large packet attack is somewhat misleadingly referred to as 'Ping of
|
|
Death` because it is often delivered as a ping packet. Ping is a program that
|
|
is used to test a machine for reachablity to see if it alive and accepting
|
|
network requests. Ping also happens to be a convenient way of sending the
|
|
large packet over to the target.)
|
|
The large packet attack has caused no end of problems to countless
|
|
machines across the Internet. Since its discovery, *dozens* of operating
|
|
system kernels have been found vulnerable, along with many routers, terminal
|
|
servers, X-terminals, printers, etc. Anything with a TCP/IP stack is in fact,
|
|
potentially vulnerable. The effects of the attack range from mild to
|
|
devastating. Some vulnerable machines will hang for a relatively short period
|
|
time then recover, some hang indefinitely, others dump core (writing a huge
|
|
file of current memory contents, often followed by a crash), some lose
|
|
all network connectivity, many rebooted or simply gave up the ghost.
|
|
|
|
[ Relevant IP Basics ]
|
|
|
|
Contrary to popular belief, the problem has nothing to do with the
|
|
`ping` program. The problem lies in the IP module. More specifically,
|
|
the problem lies the in the fragmentation/reassembly portion of the IP module.
|
|
This is portion of the IP protocol where the packets are broken into smaller
|
|
pieces for transit, and also where they are reassembled for processing. An IP
|
|
packet has a maximum size constrained by a 16-bit header field (a header is a
|
|
portion of a packet that contains information about the packet, including
|
|
where it came from and where it is going). The maximum size of an IP packet
|
|
is 65,535 (2^16-1) bytes. The IP header itself is usually 20 bytes so this
|
|
leaves us with 65,515 bytes to stuff our data into. The underlying link layer
|
|
(the link layer is the network logically under IP, often ethernet) can seldom
|
|
handle packets this large (ethernet for example, can only handle packets up to
|
|
1500 bytes in size). So, in order for the link layer to be able to digest a
|
|
large packet, the IP module must fragment (break down into smaller pieces)
|
|
each packet it sends to down to the link layer for transmission on the network.
|
|
Each individual fragment is a portion of the original packet, with its own
|
|
header containing information on exactly how the receiving end should put it
|
|
back together. This putting the individual packets back together is called
|
|
reassembly. When the receiving end has all of the fragments, it reassembles
|
|
them into the original IP packet, and then processes it.
|
|
|
|
[ The attack ]
|
|
|
|
The large packet attack is quite simple in concept. A malicious user
|
|
constructs a large packet and sends it off. If the destination host is
|
|
vulnerable, something bad happens (see above). The problem lies in the
|
|
reassembly of these large packets. Recall that we have 65,515 bytes of space
|
|
in which to stuff data into. As it happens, a few misbehaved applications
|
|
(and some specially crafted evil ones) will allow one to place slightly more
|
|
data into the payload (say 65,520 bytes). This, along with a 20 byte IP
|
|
header, violates the maximum packet size of 65,535 bytes. The IP module will
|
|
then simply break this oversized packet into fragments and eschew them to
|
|
their intended destination (target). The receiving host will queue all of the
|
|
fragments until the last one arrives, then begin the process of reassembly.
|
|
The problem will surface when the IP module finds that the packet is in
|
|
fact larger than the maximum allowable size as an internal buffer is
|
|
overflowed. This is where something bad happens (see above).
|
|
|
|
[ Vulnerability Testing and Patching ]
|
|
|
|
Testing to see if a network device is vulnerable is quite easy.
|
|
Windows NT and Windows 95 will allow construction of these oversized
|
|
packets without complaining. Simply type: `ping -l 65508 targethost`. In
|
|
this case, we are delivering an oversized IP packet inside of a ping packet,
|
|
which has a header size of 8 bytes. If you add up the totals, 20 bytes of IP
|
|
header + 8 bytes of ping header + 65,508 bytes of data, you get a 65,536 byte
|
|
IP packet. This is enough to cause affected systems to have problems.
|
|
Defense is preventative. The only way to really be safe from this
|
|
attack is to either ensure your system is patched, or unplug its network tap.
|
|
There are patches available for just about every vulnerable system. For
|
|
a copious list of vulnerable systems and patches, check out a 'Ping of Death'
|
|
webpage near you.
|
|
|
|
daemon9
|
|
Editor, Phrack Magazine
|
|
(daemon9@netcom.com)
|
|
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
To: route@onyx.infonexus.com
|
|
From: xxxx xxxxxxxxxxx <xxxx@xxxxxxxxxx.com>
|
|
Subject: Re: ?
|
|
Status: RO
|
|
|
|
Actually, hang on. I've looked your story up and down looking for ways to
|
|
make it more interesting and I can't. I think it's actually just too
|
|
technical for us and lacks a newsworthiness that was evident in the SYN
|
|
article. I mean, you never tell us why we should care about this, and
|
|
frankly, I don't know why we should. So, you're welcome to take another
|
|
pass at it, otherwise, I'll give you the kill fee of $100.
|
|
|
|
xxxx
|
|
|
|
[ Too techinical? Any less techincal and I would have to make everything
|
|
rhyme so people wouldn't fall asleep. ]
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
----<>----
|
|
|
|
|
|
Netware Insecurities
|
|
Tonto
|
|
|
|
[the rant]
|
|
|
|
I realize that to most security professionals and
|
|
system administrators who will see this magazine,
|
|
the term "NetWare security" is a punchline. That
|
|
unfortunately does not change the fact that many
|
|
people in the field, myself included, must deal
|
|
with it daily. Really, honestly, I do agree with
|
|
you. Please don't write me to tell me about how
|
|
futile it is. I already know.
|
|
|
|
Since its release, not much security news has really
|
|
surfaced surrounding Novell NetWare 4. A lot of the
|
|
security flaws that were present in 3.1x were 'fixed'
|
|
in 4.x since Novell pretty much redesigned the way
|
|
the user/resource database worked, was referenced,
|
|
and stored. Some flaws remained, although fixes for
|
|
them are well-known, and easily applied. However,
|
|
NetWare 4 came with its own batch of new security
|
|
flaws, and Novell has done a poor job of addressing
|
|
them, hoping that consumer-end ignorance and the
|
|
client/server software's proprietary design will hide
|
|
these holes. You'd figure they would know better by
|
|
now.
|
|
|
|
The ability to use a packet sniffer to snag RCONSOLE
|
|
passwords still exists; NetWare 4 institutes client-end
|
|
authentication to implement its auto-reconnect feature;
|
|
the list goes on. Below are just a couple of examples
|
|
of such bugs and how to deal with them. As new Novell
|
|
products bring many existing LANs out onto the Internet,
|
|
I think you will see more of this sort of thing coming
|
|
to the surface. I hope that when it does, Novell decides
|
|
to take a more responsible role in security support for
|
|
its products. I'd hate for such a widely used product
|
|
to become the next HP/UX.
|
|
|
|
|
|
[the exploits]
|
|
|
|
[BUG #1]
|
|
|
|
This bug is known to affect NetWare 4.10. It's probably present in 4.01
|
|
and other versions that support Directory Services, but I haven't
|
|
verified this. I'm only a CNA, so I tried to verify this bug by talking
|
|
to a group of CNEs and nobody had heard of this, although there are
|
|
apparently other bugs in previous versions of LOGIN.EXE.
|
|
|
|
The bug is a combination of some weak code in LOGIN-4.12
|
|
(SYS:\LOGIN\LOGIN.EXE) and a default User object in NDS - the user template
|
|
USER_TEMPLATE. LOGIN allows input fields to be passed directly, instead
|
|
of filtered, if they are passed to LOGIN correctly -- by specifying an
|
|
object's context explicitly (as opposed to implicitly by using CX) and
|
|
putting the User object's name in quotes.
|
|
|
|
F:\PUBLIC>LOGIN SVR1/"USER_TEMPLATE"
|
|
|
|
For Server object SVR1 in an appropriate context, this would probably work
|
|
and give a generic level of user access, perhaps to other volumes,
|
|
programs, etc. That will vary depending on the setup of the server.
|
|
|
|
The fix is simple. Load SYS:\PUBLIC\NWADMIN.EXE and disable the user
|
|
template's login. But from now on, you will have to manually enable
|
|
login for any new User objects created in your tree.
|
|
|
|
|
|
[BUG #2]
|
|
|
|
This isn't a bug as much as a failed attempt to add security to a DOS file
|
|
system. But since Novell touts (and teaches) it as a file system security
|
|
tool, it is worth addressing.
|
|
|
|
NetWare comes with a tool called FLAG, which is supposed to be the NetWare
|
|
equivalent of UNIX's chmod(), in that it controls file attributes for files
|
|
on local and NetWare file systems. The problem lies in that Novell
|
|
thought it would be neat to incorporate its tool into the world of DOS file
|
|
attributes as well. So they made FLAG alter DOS file attributes
|
|
automatically to correspond with the new attributes installed by FLAG.
|
|
This would've been cool, except that DOS's ATTRIB.EXE can also be used to
|
|
change the DOS-supported file attributes set by FLAG. (Archive, Read-only,
|
|
Hidden, and System, respectively) And since ATTRIB doesn't reference NDS
|
|
in any way, the problem is obvious; A file that was marked Read-only by
|
|
its owner, using FLAG, could be compromised by a user other than its owner,
|
|
with ATTRIB, and then altered or deleted.
|
|
|
|
There isn't an easy fix for something that is this broken, so it is
|
|
simply recommended that you use IRFs (carefully) to designate file rights
|
|
on your server.
|
|
|
|
|
|
[ 01-07-97 - Tont0 ]
|
|
|
|
|
|
----<>----
|
|
EOF
|
|
|