What's New!

Chat with

How to Defend
Your Computer 

The Guides
to (mostly) 
Harmless Hacking

Happy Hacker 
Digests (old stuff) 

Hacker Links 


Meet the 
Happy Hacksters 

Help for 



It Sucks 
to Be Me!

How to Commit
Computer Crime (not)! 

What Is a 
Hacker, Anyhow? 

Have a 
Great Life! 

News from the 
Hacker War Front

Carolyn's most
popular book,
in 4th edition now!

For advanced
hacker studies,
read Carolyn's
Google Groups
Subscribe to Happy Hacker
Visit this group

April 2, 1999
See the Happy Hacker web site at http://www.happyhacker.org
URL of the day: http://www.insecure.org

Editor's Comments
Nuggets of Info
Reader Questions
Reader Submissions
Buffer Overflows Continued
Next Issue

      *** Editor's Comments

Something occurred to me this morning, as I was reading hackernews.com --
Some of you may be taking material you read on the internet as gospel just
because it has a well-known name behind it. HNN prefaced their 'hacked
pages' list today by saying that mistakes do happen, and unless otherwise
stated as true, may not be. I'd like to put in this quick disclaimer about
anything I write here: I'm not perfect and can make mistakes. If I do,
please let me know, and I'll make an amendment in the next digest. If you
see something as suspect, email me, and I'll try to clear up any
confusion. Hopefully I won't have to ever post a retraction due to bad
info, but the possibility is there. Thanks for keeping this digest alive
and for the incredible response! Oh, and if some of you out there have a
really hard time writing me in English, I do understand German and Danish,
so if your English is very poor, I'll do my best to translate. You can try
Spanish, French or Portuguese, but I'll just be running it through
babelfish.altavista.com, and it may not be completely accurate. Or
better yet, you can use babelfish and send the result to me. It may
not be perfect English, but I'll probably understand what you say. Please
only use non-english languages if you really have something important to
contribute and really can't use english. (It takes alot of work to
translate) I just wanted to say this so you non-english speakers don't
feel left out. (And sorry, but my responses will most likely be in
English) Oh, and if you're including a nifty little exploit you came up
with in a post, please explain what does what, so I don't have to wade
through your source and comment it myself.

      *** URLs

nmap - the all-in-one network scanner

What happens when people hang out with computers too long - I loved it

"Smashing the Stack for Fun and Profit" by Aleph One

      *** Poll

Amid all the Linux hype, one poster was wondering why choose Linux over
Windows 95/98, or vice versa(!?) No rants necessary. A simple list of
reasons will do. So:

Which is better: Windows or Linux, and why?

I'll compile the results, along with my answer, as soon as I get
enough responses.

      *** Nuggets of Info

1) AOL does not work with Linux. Look in your Yellow Pages under "Internet
   Service Providers" to find someone who will give you better service for
   your Linux (and Windows) connectivity needs.

      *** Reader Questions

RC Johnson wrote:

I actually had the free time to sit down and read this one just as 
soon as  I got it, and I thoroughly enjoyed it.  Looking forward to that 
more info. on Buffer Overflow's you mentioned.

This message is not entirely a praise though, it actually has a 
question too.

A few weeks ago   /* more like months now*/ someone had done 
some sort of lookup to see what os a particular server was running.  
Do you suppose they did this simply by telneting to that box, and 
getting it in a logon screen, or is there a service that provides this 
most valuable information in some sort of response to say a ping, or 

Thanks alot, 
Keep up the great work.

[Ed- What you're looking for info on is called 'OS Fingerprinting' which
can be performed a number of ways, the simplest of which is exactly as you
stated, reading the telnet banner. This banner (/etc/issue.net in Linux)
can easily be changed so it's not so obvious. An excellent tool for
determining OS type by the way the computer responds to certain TCP
packets is nmap (available at the address above) I encourage all of you to
read the documentation at the website. It offers some very informative
texts on the topic.]

      *** Reader Submissions

Nils van den Heuvel <n.heuvel@wxs.nl> mildly flamed:


> If one is of a certain mindset, one can also set up a daemon that
> portscans the computer used by someone who runs an attack against you
> so as to see what vulnerabilities your attacker has.  Then log all this
> for a handy list of all your attackers and how they could be
> compromised.  If one wants the most vicious of revenges, one could
> email the attackers with descriptions of how you could have broken in
> and rmed them, but you just didn't find it worth your while:)


Besides pathetic (boasting about things you could have done to 
them... pffff... that is VERY immature) it would also be very stupid 
and dangerous... If someone would send some packets to 
daemons protected by this STUPID mechanism with a spoofed 
source address your script would be fooled and would scan the 
computer that really owns the ip address that the attacker used as 
the source address... You can get some (possibly dangerous) 
people VERY angry this way... There are a lot of other possibilities 
for people to exploit this system, bugtraq had a thread about them 

[Ed- Yes, this is true. You could mistakenly target some innocent
bystander this way. This seems to me as a 'middle ground' between passive
network monitoring and the 'strikeback' method hyped up by the press
fairly recently. Now here, you're not actually doing anything totally
offensive, but instead, doing a little 'reconnaissance' instead. My guess
is that most sysadmins on the target end would be sympathetic to the
events leading up to the scan. Others (possibly dangerous, as you put it)
would not be so forgiving. I'm glad you pointed this out, but I think it
could have been more tactfully stated.]

------ quote -------

I'm working on a working module of the same. Would let you 
know when I have it fully running. Its interesting to note
that this is all documented info. Nothing is illegal ;-)
All it does it get all possible info using ident and finger.


If you plan on including portscanning in this module then this can 
be illegal... I recently read about some state or country (don't 
remember exactly) where portscanning is illegal...


ps. Including a programming corner is a great idea, but can you 
do C instead of C++ please??? :-)

[Ed- Nope. Sorry to be so blunt, but I like C++ better. Yes, UNIX was
coded in C, and alot of people still use it. I don't want to start another
holy war here, so I'll leave it at that. I'll try to keep my preference
for C++ in check if I do end up doing a 'corner'.]


Ktinga! <ktinga@nmt.edu> wrote:


  I would like to share my thoughts about the "Fake" shell that appeared
in the most recent UNIX HH digest.

  At most schools (large or small), there is some sort of distributed
setup like NFS, NIS, or SAMBA. There are a machines that are meant for
general purpose usage by almost all users, such as students, faculty,
staff, and guests of the university. There are a few special machines
that people should not have access to, but are still on the distributed
network. Examples include machines configured as routers (sometimes the
root domain, like ucla.edu), mail servers, etc. Interestingly enough, a
school I attened in the Land of Enchantment had it's web server do double
duty serving files to the web and acting as a general use machine (and
broke nary a sweat, even during peak hours).
  That is to say, if you were to telnet to the mail server and did
have access to it, more often than not, you would feel as though you are
logging into a normal general use machine.
  The Fake shell is usually used to bar access to normal users and
allow special users into the sensetive systems for what ever purpose
(maintenence, auditing, [revenge in the case of mail severs], etc). I
believe NIS can be configured like this. The Nutshell book (like all of
them) is a very good source. You'll probably find it on sale somewhere.
  Fake shells (lock shell, noauth shells, as they are sometimes
called) are usually created by the wise system administrator or leached
off by the not so wise one (like me). 
  Someone could use a lock shell instead of an '*' in the /etc/passwd file
to lock out accounts like bin, uucp, nntp, etc. However, it is most
likely wise to leave it with an asterisk. As the UNIX digest
administrator mentioned, this could be used for POP users, since they
have to be able to get their mail, but never be allowed to log in to the
actual machine.
  Here is an example:


cat << EOF

This account is locked. Deal.


  If you were to copy the previous text into a file, made it executable
(using chmod), add it to /etc/shells and select it as a shell, you would
have a working shell that did nothing but...

hannah:/home/ktinga> telnet hannah
Trying ...
Connected to hannah.
Escape character is '^]'.

Linux 1.2.8 (hannah) (ttyp0)

login: ktinga

This account is locked. Deal.

Connection closed by foreign host.

  And that, is a Fake shell.

[Ed- Thanks for the good explanation, Ktinga!]


Michael Randall <mrandall@tampabay.rr.com> wrote:

In Hacker Digest, UNIX, you wrote:

[Ed- Your current directory (.) is not in your path. When you type in a
command like filename without any path info, the shell will search
through a list of likely places the executable would reside. In tcsh,
the shell I'm using at the moment, the path is set in ~/.cshrc like so:
set path=(/usr/local/bin ...other stuff...) It's a space-delimited list
of likely directories that contain executables. If you put '.' without
the quotes at the end of the list of directories, your script should
work correctly, because your shell will look in the current directory
last for any executables.]

---end of inclusion --

PLEASE NOTE: Putting dot '.' in your path is a potential security hole.
If someone drops a trojan horse program and you trip over it by running
it in the right directory, (for instance naming it 'ls'), so instead of
putting '.' in your path (or PATH for Bourne shell & derivitives),
create a bin directory in your home directory, and add "~/bin" to your
path instead, or /home/username/bin if you prefer.

Michael W. Randall

[Ed- Yep, I'll agree here too. However, if I'm not mistaken, the shell
will search through your path first to last, looking for a matching
command. If something isn't found in your standard path, it will finally
look in ./ for it. So if a person does type 'ls' and there is a trojan in
their current directory, it shouldn't be executed unless ls is otherwise
unreachable from the current path. But I would recommend doing what
Michael suggests in creating a personal binary directory ~/bin to run
your scripts.]


Anderson Luiz Ravanello <rock@spei.br> wrote:

Greetingz, my friends!!!!

About the following problem, I've a most simple answer:

>David Webber <dwebber@ie-e.com> wrote:
>I have a Red Hat 4.2 system that I do not know the root password to. The

IF Mr. David has LILO correctly set up, upon boot, he may simply type in:

Linux (or boot label here) single

That will leave him with a bash shell and root privileges, thus being able
to passwd anyone he wants, including root

Hope I could help in any way.
Best Regards,


Jan Svenungson <jan.svenungson@swipnet.se> wrote:

Howdy folks.
First of all, great work with the *nix digest, keep up the good work.
I have to say something about the kernel article in the last digest.
First of all, a good thing to do is putting your new kernel source in
/usr/src/linux-2.2.2 (assuming you have the 2.2.2 release of course) and
then make a symlink from /usr/src/linux to that directory ("ln -s
linux-2.2.2 linux" in the above example). That way you can save the old
source if some peculiar problems should arise (Not that i have had
problems but better be safe than unable to compile the new kernel after
deleting the old). The "make mrproper" will do the same as "make clean"
but some more cleaning, including deleting your configuration file so
better back it up before issuing "make mrproper". Me personally usually
do the usual "make clean" and if the kernel behaves really strange after
recompiling i du a "make mrproper" and then recompile again. 
After configuration (with "make config", "make menuconfig" or "make
xconfig", your choice) i usually just write "make dep ; make clean ; make
zImage ; make modules ; rm -rf /lib/modules/2.2.2 ; make
modules_install". You might use bzImage or whatever. The "rm" command
deletes the previously compiled modules and should be used with care i
guess. When you have compiled the kernel you will have to copy it over
your old kernel and run lilo again but please dont just make a backup of
your old, copy the newer kernel, run lilo and reboot. If the new kernel
somehow does not work you'll have to dig through your pile of boot/rescue
discs which is frustrating. Instead copy you old kernel to, for example,
"/vmlinuz.old" and make a new label in lilo for it. Example  
image = /vmlinuz
  root = /dev/hda1
  label = linux
image = /vmlinuz.old
  root = /dev/hda1
  label = linux.old
That way you dont have to get angry when your new kernel does not work,
you just reboot and boot the old kernel and try to recompile again.
Last but not least, dont expect your linux box to be extremely much faster
with alot more free memory just becouse you recompile the kernel and
configure it 100% for you system. A couple of extra stuff in the kernel
seldom couse trouble if you have a computer with some extra RAM, this
"recompiling fever" is really only interesting for people with computers
that arent that fast and dont have much RAM. But i dont want you to _not_
recompile, at least you will learn how it works and even if it might now
increase the speed notably it wont make it slower either.
Excuse me for all typos and bad grammar, english isn't my first language.
Happy compiling! Jan Svenungson.

[Ed- Thanks Jan! I guess I tend to gloss over some important points for
the sake of simplicity, but I'm glad you are all willing to contribute!]

      *** Buffer Overflows Continued

Enigma3 <free_knowledge@hotmail.com> wrote:

I subscribe to bugtraq and I see all of these buffer overflow problems, 
but they all seam stupid to me. Well only the ones that saw, COMPROMISE 
PINE, as an email address type in e where e is over 70 and I say well 
that seems dumb that any program will crash.  But to my point, how can a 
buffer overflow gain root access?  I don't mean it to say how do I hack, 
but like I heard of an ftp root problem.  If you log into sight a login 
in with a where a is over 70, will it cause the login script to fail? Or 
something like that?  Or are there any examples where buffer overflow 
can get me somewhere in a machine, more like is, I mean I would be happy 
just to get in ?  Well any help would be great.


[Ed- Well, I'll pick up where I left off at the last article about buffer
overflows, and try to answer some of Enigma3's questions. (and the rest of
yours as well) Note: I _do_ gloss over certain details, as I'd like
everyone to be able to get something out of this.]

I mentioned before that certain programs that access privileged ports, as
well as those needing access to special files (like /etc/shadow) need to
run as root to take advantage of the reduced restrictions. These programs
are run 'setuid root' which means that the user id (uid) they run as is 0,
which is root, the account with divine control over the entire computer.
Enigma mentions that compromising pine seems stupid. For the most part
he's right, as pine normally runs as the user who started it - you! So
being able to do things you normally could anyways doesn't seem all that
appealing. If, however, pine were run as root, the following could happen.
I start thinking about what I'd want if I could make root do anything I
wanted. Well, the most obvious and most powerful tool to have initially is
a shell that lets me execute commands as root. And now time to repeat

"Try this at home! Please don't try this anywhere where you haven't been
given explicit permission to do so. Picture Carolyn glaring at you,
shaking her finger, giving you the 'You can go to jail warning'. It is
illegal to access another person's computer without their permission."

[RUST:(Random Use[ful|less] String of Trivia) This may even include
 portscanning in some areas.]

So how would we go about that? Well, consider the following code snippet:

-- oflow.c

#include <string.h>

main(int argc, char* argv[])
  char buf[10];

// error checking skipped
  strcpy(buf, argv[1]);

-- end oflow.c

What this program does, for the C/C++ challenged, is it takes the first
argument on the command line and copies it into a chunk of memory called
'buf' which is 10 characters long. So, if you type the following (assuming
oflow is the name of the program):

oflow test

The program will put the string "test" into the array buf. What happens
when you do this?

oflow "MommyCanIGoOutAndKillTonight?"

Well, besides getting the Misfits fans of the digest going, it may do one
of a couple things:

1) Nothing. The program exits normally.
2) The program spits out a Segmentation Fault error or something similar.
3) The computer will answer, "Yes."

If your computer does number 3, please shut down your computer gracefully,
unplug it, repackage it, and ask the devil to take it back (minus
shipping and exorcising). The first 2 are completely normal responses. If
the program seg faults, it means you overwrote an important portion of
memory, and the program began to execute invalid code. Number 1 means you
got (un?)lucky and didn't affect the program significantly. If this
happens, try again with a longer string. Chances are, eventually you'll
screw something up. And this screwing up is where the chance for evilness
appears. When I said the program began to execute invalid code a few lines
up, you observant readers thought, "What if...?" Indeed, what would
happen if that code wasn't invalid. What if it actually did something? And
now we get to the fairly painful part of the exploit-coding process:
generating machine-readable code to give us a root-privileged shell. The C
code above is not machine-readable...it must be run through a compiler
first. So shoving some C code into the place where the computer starts
executing code isn't going to do you any good. Speaking of that, we need
to find _by_how_much_ we need to overflow the buffer to make it execute
our cleverly-inserted code. I'll leave this one up to you...a simple way
of doing it is simply trial and error. So, we're at the point where we
need some machine-readable code. But another monkey wrench is thrown into
the gears: different types of processors use different types of machine
language. This means that your exploit will be specific to the type of
machine (i.e. Sparc, Alpha, or x86). To get any farther with this process,
it's very important to know assembly language on the platform you're
targeting. And if you know that much, you've already got a decent idea on
how to create that machine code. If you're really stuck at this point,
grab a canned buffer overflow exploit from rootshell and look for the
machine code portion. Ok, now that I've glossed over that important detail
of generating the code, I'll move on to what you actually do with it.
First, you'll put the code into a big array, called shellCode, for
example. Then, you need to put the address of this variable to the exact
point where you determined that "stuff started to break". This will cause
the program to start executing code at the beginning of your variable. If
you've done everything right up to this point, and the dummy computer
you're trying it out on is actually vulnerable to the exploit, you should
be given a root shell. Yee-Haw. 

Yes, there was alot of hand-waving in this article, and I don't claim to
be an absolute authority on the topic. Check out "Smashing the Stack for
Fun and Profit" at the URL above for more detailed technical info, if this
got you interested enough in the topic. If I made any glaring mistakes,
PLEASE let me know, and I'll correct them in the next digest. If not, I
just may have found the perfect balance of blood and caffeine in my body.

      *** Next Issue



This is a list devoted to *legal* hacking! If you plan to use any
information in this Digest or at our Web site to commit crime, go away!
Foo on you! Don't email us bragging about any crimes you may have committed.
We mean it. 

For Windows questions, email keydet89@yahoo.com or editor@cmeinel.com
For Unix questions, contact unixeditor@cmeinel.com.
For Macs, email Strider <s.corinth@iname.com> 

Happy Hacker staff: Unix editor, <unixeditor@cmeinel.com>;
Windows editor, Keydet89 <editor@cmeinel.com>; postmasters Jonathan D.
Zerulik and William Lewis <>; Hacker Wargame Director,
Vincent Larsen <vincent@sage-inc.com>; Wargame Sysadmin, Satori
<Satori@rt66.com>; Webmaster, Diode <webmaster@happyhacker.org>; Clown
Princess: Carolyn Meinel <>

Happy Hacker is a 501 (c) (3) tax deductible organization 
in the United States operating under Shepherd's Fold Ministries. Yes! 
This is all a plot to save your immortal souls!

 © 2013 Happy Hacker All rights reserved.