CERT and Firewalls Bird of a Feather session notes
BOFs occurred on June 9, during the Summer Usenix conference in Boston.
Although I work with a magazine parttime, I am not a reporter, nor a
particularly great note taker. And this time I used a laptop, which
died about an hour before the last stragglers had left the room
45 minutes after midnight. I'm including notes from the CERT BOF
because they seemed relevant to this list.
Notes, identifications of known speakers, and questions and answers from
unrecognized speakers are enclosed in [square brackets]. rf
[First up was Ed DeHart of CERT]
Topic: Things haunting the net right now. Majordomo alert sent out
today by CERT.
[Ed lets Brent Chapman speak:]
Quickly, when I wrote majordomo several years ago, I was
careless in the configuration, and allowed majordomo to
send something to sendmail without validating it first. If you
send the right thing to majordomo, it passes it
to sendmail (and system()) wrong. Everything that calls sendmail with a
receipient, use a -t flag on the command line. Stop passing sendmail
recipients on the command line. Three lines to change, 1 in config
file, one in majordomo.pl, and one in request answer (in new list).
For new versions of majordomo, try
ftp.greatcircle.com:pub/majordomo or ftp.pgh.net:pub/rouilj
or ftp.cs.umb.edu.
[Back to Ed speaking:]
People are still using older versions of sendmail, and not running
smrsh. Scott Chasin published a script to test your sendmail to see if
you are vulnerable. We have this problem with sendmail and the
sniffer problem. Really for about the last year and half, three new
incidents a day. Now we are averaging 13 incidents a day, and the upper
limit is 65,000 sites per incident. If you can't get your vendor to
upgrade your sendmail, get Eric's (8.6.9 is the latest, and 8.6.8 has
all security fixes.) So 8.6.9 is what you ought to be running. Or look
for the Mprog line and use the new program Eric has written, smrsh. Create
a directory and create a couple of links to control which you want
sendmail to run, (or use /bin/false as the prog mailer instead of
/bin/sh).
We have always had problems with shoulder surfers. But late last year
we saw much more than normal sniffers. About a month after the last
advisory, things started heating up again. Then Phrack published the
sniffer code, and shortly after Phrack came out, the number of
incidents skyrocketed. Sendmail, rdist, or unpatched divide
by zero bug in Sun, and taking advantage of these old problems to
become root. Get login from sniffed passwords. Anything having to do
with logins (telnet, ftp), programs log to a diskfile, and come back
later and pick it up. Usually use a Sun system they think is unused.
Even Kerberos daemons are being replaced--Kerberos is not really
running anymore, and most users don't have a clue. More and more
sites have naive operators. Even though Kerberos and wrappers and a
lot of things are available, not enough people are using them.
Found out just before I left, an incident was noticed where the
intruders were there for three or four months before the site noticed
them. It makes it very difficult to help someone who is not helping
themselves. The first time someone worries about security is after
they have spent several days cleaning up.
Most of the sniffer incidents we have found has been harvesting
passwords. Lots of public access networks and regional networks, so a
awful lot of time has been spent sniffing.
More insurance companies are coming out with loss figures, so use this
with your managers to help convince them you need more security.
[Could CERT provide a short list of attacks currrently being used?]
No. We have a lot of old material, on-line materials, we have
tutorials, but there is a limit to what we can do. But no checklist.
Appendix A of Spafford and Garfinkle, and the Dave Curry paper especially
good for Sun systems. And there is CERT FAQ, and Curry has a book.
And there is a README file in the [CERT] advisory directory.
[Perry Metzer about mission of CERT. And bringing up his issue with
CERT last November. Eventually, he came up with enough information to
solve his problem.]
ED: Your communication path is the vendor you bought from. First
problem was only in Sun, but there turned out to be a similar problem
in other systems which showed up later. Anytime we give out
information, once its out of our hands, we have no control what happens
to it.
Unless we have a vendor support solution there's nothing we can do.
[A Metzer lead flame session goes on for 10 minutes][Someone points out that
they should stop buying Sun if they won't fix it.]
[Someone makes comments about HP security, and ED talks about how HP has
improved their position in regard to security patches.]
[Steve Bellovin asks if there is a checklist for vendors?]
ED says vendors don't like to sit in the same room, but they have had
vendor meetings, and got 20 different vendors in the same room.
[Has a liability position been formed?] ED: yes it has, but there is
no case to point to yet.
[Is there any other sniffer software out there?] ED: Nope, since it was
published in Phrack, that's what most people are using. And there is
a source routing kit being used, so if you are using a filtering
router, you must disallow source routing.
Most popular attacks currently are:
1) sniffer, 2) sendmail, 3) source routing. Sniffer was specifically
for Suns, but there is also a tcpdump version. The main problem was
/dev/nit on Suns.
Sites that have put up a firewall, have added tcpwrappers, and have some
way of doing proactive checking, they don't get bothered as much. Put
up some resistance. A router is not enough, but if you are using a
router, turn off source routing.
Site security improvement program from CERT. Also, there are groups
out there like TIS, who can help with site security, and there are
enough people out there doing security consulting.
[Fred Avolio of TIS slips ED a buck...]
[Nothing replaces having one person responsible for computer security,
and pays intention mainly to security. Secondly, ftp is really good,
but gopher would be nice (a gopher menu of all the advisories).]
ED: Is gopher secure or not, so we will probably be putting up an
information server. CERT now has technical writers assigned to them, so
hopefully some WWW service will appear in the next couiple of months.
[MIT admin, says it is well worth it to take the time to install all
the patches, rather than spend the time cleaning up later.]
Ed DeHart steps down, and Brent begins Firewalls BOF.
BC: Dave Dalvas from TIS will speak second, firewalls mailing list first.
Firewalls mailing list formed after Usenix security symposium in 1992,
and after a firewalls BOF, people said we'd like to have a mailing
list to follow this. We had 600 by the end of the first week.
Now a WAIS database, wais.greatcircle.com, for context searches.
Almost 3000 subscribers, and about double with redistribution. Top
five domains: 1280 COM, 440 EDU, 152 GOV, 116 AU, 98 CA. 1946 on
firewalls, 892 on digest. Large international presence (about 25%).
Dave Dalva of TIS: I will talk about TIS and their project with Mosaic.
{What are the threats?]
Anybody not know what HTTP is (underlying protocol of WWW)?
There are two modes of operation. Client can fan out to any number of
servers. The other mode is where there is an intermediary proxy, which
may be running on the firewall, where the proxy invokes the real protocol
between the client and the server.
Here's an URL: ftp://wustl.edu. The real dialogue goes on between proxy
and server, and client and
proxy talk in html (Hyper text markup language), proxy is really
acting as a converter between html and ftp in this example.
Threats: Two basic threats are trojan horses and bypassing security
policy. Second one first, violating your firewall security policy. If
you tell your proxy to go gopher for you (which your policy and
firewall might try to prevent), the Mosaic proxy gets around them.
A famous trojan horse is a URL which looked like this:
telnet://foo.edu; rm *
Mosaic uses system() to do a lot of things, so a URL with a semicolon
and additional commands can be set up by anyone who controls a Mosaic
server.
Programs used to interpret (and display) the files acquired by Mosaic
can also be a problem. For example, PostScript can delete files, or
write a string which can do the same thing. Ghostwrite does the right
thing. Another nasty trojan horse is arbitrary interpreters. Using
Mosaic, it gives you the ability to specify your own data interpreter.
For example, I can invoke troff to interpret troff files. MIME is
the base source for this problem, but in the MIME document it at least
lists the problems possible.
There are solutions, some are more trivial than others. First one is a
firewall, and use of a proxy, or an application gateway, can have your http
proxy present with a proxy scheme when you want to telnet out. Script
problem is harder. First would be to validate the http/html data
coming down the pipe, see if it follows the data definition for URLs.
Another one is to validate interpreted language (like Postscript).
You could filter out certain characters, screen troff for .ti.
Steve Bellovin says filtering this won't work, you need to use a
special version, such as ghostwrite without the write string operator
(to prevent the creation of a delete operation, or something else
harmful).
[Marcus Ranum:] This is a variation of the virus problem. We
can't figure out all the stupid ways people will import stuff. How
we can minimize damage to your systems.
Run the clients and the interpreters in some kind of a restricted
environment, something like chroot, like running ghostscript with the
file also down in the chroot.
Another idea is generically called type enforcement. You label files
and packets as a specific type, and a set of programs which live in
domains, and finally a mapping between the domains and types. This is
a great way to limit the damage things can do. Contact info is Dan
Sterne, sterne @
tis .
com .
Steve Bellovin points out that the code inside the chroot
could be replaced with something unsafe which could do harm.
Analyze the code--take a look at the 14 million lines of code--but it
is theoretically impossible.
[Someone might bring in something, move it out of the restricted area,
and run it. People are packrats, how will you prevent this?]
[Dave again] We are thinking of only allowing you to
connect to known good sites, or using public key encryption to
authenticate the sites you talk to.
[Are you saying you would never let your users download files?]
Well, no. Just that we will control the client.
[more discussion].
[I won't run Mosaic until I trust it.]
[Brent Chapman] Someone can do SLIP around your firewall.
[It's hard to prevent your users from sending
themselves mail bombs. I am more concerned about someone mucking with
a server and mail bombing a client.]
[Steve Bellovin] Mosaic makes all these things
much easier, finding pages and finding bombs. To see this really
nifty movie, type this line on your screen.
[Marcus Ranum] Mosaic appeals to your most ignorant users, and you're
saying educate them? If we have to manually have to examine every bit
coming into your system, then we need to be consistent, and check
email, bitmap decoders, ftp, etc.
[Turn off the dangerous things, like removing files.]
[People can up with very creative ways to get around firewalls, like
tunneling through telnet, using SLIP.]
[Troff isn't broken, Mosaic is. Could implement a minimal troff...
and Mosaic is the Internet. If you can't have Mosaic, people will try
to get around you. You can proxy for it, and we do provide Silicon
Graphics with Mosaic, and its not easy to adminsiter all our
distributed sites.]
[Marcus: How many people in this room are using plaintext, repeatable
passwords to come in from the Internet? If you are worrying about
Mosaic, but coming in from the Interent with plaintext passwords, you
have other things to worry about. Security is not in such a good
shape. Mosaic has only been offered for a short while, while we have
had ftpd with security wholes for many years. So let's be calm, let's
be sensible, and treat this problem with the right level of support.]
[Comments about Raptor? ]
[Brent Chapman] One of my concerns about canned, off-the-shelf solutions.
A critical application in a fast changing field, and you have to know
what you are getting. Yes there are canned solutions, but they make
me very nervous because I don't know if the sites can react to new
problems, or know what they are getting.
[I approve of "teach your man how to fish (rather than give him a
fish)", so you can sleep at night.]
[Canned solutions can provide a false sense of security.]
[You cannot buy a product which allows you to manage different forms
of connectivity.]
[You always have to keep in mind what you are protecting. Why patch
Mosaic? ftp is boring, people have been cracking ftp for 20 years, but
Mosaic is exciting.]
[Chapman?] Another factor to consider is your time to recover from an incident.
If somebody comes in and destroys your system, can afford the time
before you can can come back on line.
[Consider your visibility. Name something outside your firewall, and
call it ford.com with pictures of cars. But if somebody cracks it, it
will be on the front page of the paper.]
[Chapman] There's always something that someone can exploit. My goal
is to slow them down enough, maybe see them coming.
[Marcus] The advantage of restricting the firewall down as much as
posssible is to close down all but a few, small chinks in your armor
for someone to stick a knife into.
[A question directed at Bellovin/Cheswick: When do you start paying attention
to someone trying out your defenses?]
[Bill Cheswick] It depends on who you are. The answer for us is our
defense get probed 40 times a week casually, and three times a
week seriously. How often are you probed (we asked other companies),
and they are getting probes about a third as much. Put in some traps,
like tftp or a phony guest account which just logs knob turning.
[Steve Bellovin] What we do depends on the nature of the probe. Set up
a fake fsp, because if there are a large number of people trying one of these
tests, you probably have some weakness that has been posted to a BBS.
We get a lot of probes.
Just because you are secure doesn't mean they are not out to get you.
They are out to get you.
[Allen Lum: How is whitehouse.gov set up?]
[Marcus Ranum] I used to agree with the set-up-traps and pull-the-wings-
off-flies mindset.
But I was sending entirely too much time trying to track down college
kids. This was compounded by setting up whitehouse.gov. Attacks on this
machine are the concern of the US Secret service. So you must set up a
reasonable threshold. Something we could not identify a being
successfully deflected. This is the model I like today. If you get
hit by something you haven't seen before, then you need to be alarmed.
You can't get the password file. Keep IP statistics on netstat, can
set up arbitrary types of queries.
I set up a sucker to collect all the connections to whitehouse.gov,
and I got 16 mbyte on the first day. Keep users off your firewall,
so if someone logs into the box you know
you have a problem. Figure out what are the categories of things that
make you want to push the panic button.
[Battery warning sounded at this point. Obviously, I didn't take note
of all that was said in the 2.5 hours before the laptop wanted a
rest...]
Rik Farrow
rik @
uworld .
com
|
|
