mirrors/phrack
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
phrack/phrack50/3.txt

596 lines
26 KiB
Text
Raw Permalink Normal View History

feat: init
2022-06-06 12:59:29 +05:30
.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
Reference in a new issue Copy permalink