mirror of
https://github.com/fdiskyou/Zines.git
synced 2025-03-09 00:00:00 +01:00
215 lines
11 KiB
Text
215 lines
11 KiB
Text
![]() |
---[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 01 of 15
|
||
|
|
||
|
|
||
|
-------------------------[ P H R A C K 5 3 I N D E X
|
||
|
|
||
|
|
||
|
--------[ Rumble in the Mumble
|
||
|
|
||
|
|
||
|
More than 6 months have passed since our last offering. My most humble,
|
||
|
sincere and heartfelt apologies. At long last, here we are. Better late then
|
||
|
never, that's what I always say. Unless of course, the late version sucks,
|
||
|
then I just like to disavow it entirely. Well, here we go again. Another
|
||
|
Phrack issue to glorify behavior which would otherwise be classified as
|
||
|
sociopathic or frankly psychotic (according to Mich Kabay). More of what you
|
||
|
want, more of what you need. Technical articles on fanatically enticing
|
||
|
topics, lines and lines of glorious source, another gut-busting installment of
|
||
|
Loopback, and of course, the News. Mammas, don't let your babies grow up to
|
||
|
be hackers. Or hookers for that matter.
|
||
|
|
||
|
Alright. Let's get down to business. Let's talk remote attack paradigms.
|
||
|
Remote attack paradigms can fall into one of two types, based off of the
|
||
|
standard client/server communication paradigm (we are glossing over any
|
||
|
extensions to the model like client to client or server to server stuff). The
|
||
|
two attack types are client to server (server-centric) and server to client
|
||
|
(client-centric). Server-centric attacks are well known, understand and
|
||
|
documented. Client-centric attacks are an area that is often overlooked, but
|
||
|
is definitely fertile ground for exploitation. Below we look at both.
|
||
|
|
||
|
|
||
|
----[ Server-Centricity
|
||
|
|
||
|
Historically, the vast majority of remote attacks have been server-centric.
|
||
|
Server-centric, in this scope, refers to attacks that target server (or daemon)
|
||
|
programs. A common (and frequently reoccurring) example is sendmail. The
|
||
|
attack targets a server (the sendmail daemon) and approximates a client (the
|
||
|
exploit program). There are several reasons why this has been the trend:
|
||
|
|
||
|
- Server programs typically run with elevated privileges. Server
|
||
|
programs usually require certain system resources or access to special
|
||
|
files that necessitate privilege elevation (of course we know this
|
||
|
doesn't have to be the case; have a look at POSIX 6). A successful
|
||
|
compromise could very well mean access to the target system at that
|
||
|
(higher) privilege level.
|
||
|
|
||
|
- Discretion is the attacker's whim. The client/server message paradigm
|
||
|
specifies that a server provides a service that a client may request.
|
||
|
Servers exist to process clientele requests. As per this model, the
|
||
|
attacker (client) makes a request (attack) to any server offering
|
||
|
the service and may do so at any point.
|
||
|
|
||
|
- Client codebase is usually simple. Dumb client, smart server. The
|
||
|
impact of this is two-fold. The fact that server code tends to be
|
||
|
more complex means that it is tougher to audit from a security
|
||
|
stand-point. The fact that client code is typically smaller and less
|
||
|
complex means that exploitation code development time is reduced.
|
||
|
|
||
|
- Code reuse in exploitation programs. Client-based exploitation code
|
||
|
bases are often quite similar. Code such as packet generators and
|
||
|
buffer overflow eggs are often reused. This further cuts down on
|
||
|
development time and also reduces required sophistication on the part
|
||
|
of the exploit writer.
|
||
|
|
||
|
All of these make server-centric attacks enticing. The ability to
|
||
|
selectively choose a program to attack running with elevated privileges and
|
||
|
quickly write up exploit code for it is a powerful combination. It is easy to
|
||
|
see why this paradigm has perpetuated itself so successfully. However, up
|
||
|
until recently it seems another potentially lucrative area of exploitation has
|
||
|
gone all but overlooked.
|
||
|
|
||
|
|
||
|
----[ Client-Centricity
|
||
|
|
||
|
An often neglected area of exploitation is the exact reverse of the above:
|
||
|
client-centricity. Client-centric attacks target client programs (duh). The
|
||
|
types of programs in this category include: web browsers (which have seen more
|
||
|
then their share of vulnerabilities) remote access programs, DNS resolvers and
|
||
|
IRC clients (to name a few). The benefits of this attack model are as follows:
|
||
|
|
||
|
- Automated (non-discretionary) attacks. We know that, under the
|
||
|
previous paradigm, the attacker has complete autonomy over who s/he
|
||
|
attacks. The benefit there is obvious. However, non-discretionary
|
||
|
attacking implies that the attacker doesn't even have to be around
|
||
|
when the attack takes place. The attacker can set up the server
|
||
|
containing the exploit and actually go do something useful (tm).
|
||
|
|
||
|
- Wide dispersement. With client-centric attacks you can gain a wider
|
||
|
audience. If a server contains a popular service, people from all over
|
||
|
will seek it out. Popular websites are constantly bombarded with
|
||
|
clientele. Another consideration: server programs often run in
|
||
|
filtered environments. It may not be possible for an attacker to
|
||
|
connect to a server. This is rarely the case in client-centric
|
||
|
attacks.
|
||
|
|
||
|
- Client codebase not developed with security in mind. If you think
|
||
|
server code is bad, you should see some client code. Memory leaks and
|
||
|
stack overruns are all too common.
|
||
|
|
||
|
- Largely an untapped resource. There are so many wonderful holes
|
||
|
waiting to be discovered. Judging at how successful people have been
|
||
|
in finding and exploiting holes in server code, it goes to figure that
|
||
|
the same success can be had in client code. In fact, if you take into
|
||
|
account the fact that the codebase is largely unaudited from a
|
||
|
security perspective, the yields should be high.
|
||
|
|
||
|
For all the above reasons, people wanting to find security holes should
|
||
|
be definitely be looking at client programs. Now go break telnet.
|
||
|
|
||
|
|
||
|
Enjoy the magazine. It is by and for the hacking community. Period.
|
||
|
|
||
|
|
||
|
-- Editor in Chief ----------------[ route
|
||
|
-- Phrack World News --------------[ disorder
|
||
|
-- Phrack Publicity ---------------[ dangergirl
|
||
|
-- Phrack Librarian ---------------[ loadammo
|
||
|
-- Soother of Typographical Chaos -[ snocrash
|
||
|
-- Hi! I'm an idiot! -------------[ Carolyn P. Meinel
|
||
|
-- The Justice-less Files ---------[ Kevin D. Mitnick (www.kevinmitnick.com)
|
||
|
-------- Elite --------------------> Solar Designer
|
||
|
-- More money than God ------------[ The former SNI
|
||
|
-- Tom P. and Tim N. -------------[ Cool as ice, hot as lava.
|
||
|
-- Official Phrack Song -----------[ KMFDM/Megalomaniac
|
||
|
-- Official Phrack Tattoo artist --[ C. Nalla Smith
|
||
|
-- Shout Outs and Thank Yous ------[ haskell, mudge, loadammo, nihilis, daveg,
|
||
|
-----------------------------------| halflife, snocrash, apk, solar designer,
|
||
|
-----------------------------------| kore, alhambra, nihil, sluggo, Datastorm,
|
||
|
-----------------------------------| aleph1, drwho, silitek
|
||
|
|
||
|
|
||
|
Phrack Magazine V. 8, #53, xx xx, 1998. ISSN 1068-1035
|
||
|
Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved. Nothing
|
||
|
may be reproduced in whole or in part without written permission from the
|
||
|
editor in chief. Phrack Magazine is made available quarterly to the public,
|
||
|
free of charge. Go nuts people.
|
||
|
|
||
|
Contact Phrack Magazine
|
||
|
-----------------------
|
||
|
Submissions: phrackedit@phrack.com
|
||
|
Commentary: loopback@phrack.com
|
||
|
Editor in Chief: route@phrack.com
|
||
|
Publicist: dangergrl@phrack.com
|
||
|
Phrack World News: disorder@phrack.com
|
||
|
Submissions to the above email address may be encrypted with the following key:
|
||
|
|
||
|
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||
|
Version: 2.6.2
|
||
|
|
||
|
mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW
|
||
|
ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O
|
||
|
vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j
|
||
|
0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W
|
||
|
DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG
|
||
|
/v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu
|
||
|
Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=
|
||
|
=1iyt
|
||
|
-----END PGP PUBLIC KEY BLOCK-----
|
||
|
|
||
|
As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED. Phrack goes out
|
||
|
plaintext. You certainly can subscribe in plaintext.
|
||
|
|
||
|
phrack:~# head -20 /usr/include/std-disclaimer.h
|
||
|
/*
|
||
|
* All information in Phrack Magazine is, to the best of the ability of the
|
||
|
* editors and contributors, truthful and accurate. When possible, all facts
|
||
|
* are checked, all code is compiled. However, we are not omniscient (hell,
|
||
|
* we don't even get paid). It is entirely possible something contained
|
||
|
* within this publication is incorrect in some way. If this is the case,
|
||
|
* please drop us some email so that we can correct it in a future issue.
|
||
|
*
|
||
|
*
|
||
|
* Also, keep in mind that Phrack Magazine accepts no responsibility for the
|
||
|
* entirely stupid (or illegal) things people may do with the information
|
||
|
* contained here-in. Phrack is a compendium of knowledge, wisdom, wit, and
|
||
|
* sass. We neither advocate, condone nor participate in any sort of illicit
|
||
|
* behavior. But we will sit back and watch.
|
||
|
*
|
||
|
*
|
||
|
* Lastly, it bears mentioning that the opinions that may be expressed in the
|
||
|
* articles of Phrack Magazine are intellectual property of their authors.
|
||
|
* These opinions do not necessarily represent those of the Phrack Staff.
|
||
|
*/
|
||
|
|
||
|
-------------------------[ T A B L E O F C O N T E N T S
|
||
|
|
||
|
1 Introduction Phrack Staff 11K
|
||
|
2 Phrack Loopback Phrack Staff 33K
|
||
|
3 Line Noise various 51K
|
||
|
4 Phrack Prophile on Glyph Phrack Staff 18K
|
||
|
5 An Overview of Internet Routing krnl 50K
|
||
|
6 T/TCP Vulnerabilities route 17K
|
||
|
7 A Stealthy Windows Keylogger markj8 25K
|
||
|
8 Linux Trusted Path Execution redux K. Baranowski 23K
|
||
|
9 Hacking in Forth mudge 15K
|
||
|
10 Interface Promiscuity Obscurity apk 24K
|
||
|
11 Watcher, NIDS for the masses hacklab 32K
|
||
|
12 The Crumbling Tunnel Aleph1 52K
|
||
|
13 Port Scan Detection Tools Solar Designer 25K
|
||
|
14 Phrack World News Disorder 95K
|
||
|
15 extract.c Phrack Staff 11K
|
||
|
|
||
|
482K
|
||
|
|
||
|
-----------------------------------------------------------------------------
|
||
|
|
||
|
" The advent of information availability and a rise in the number people
|
||
|
for whom the net has always been 'the norm' is producing a class of users
|
||
|
who cannot think for themselves. As reliance upon scripted attacks
|
||
|
increases, the number of people who personally possess technical knowledge
|
||
|
decreases. "
|
||
|
|
||
|
-----------------------------------------------------------------------------
|
||
|
|
||
|
----[ EOF
|