Hacker found bug in Postgres ?
Hello,
this night we discovered here a strange behaviour on our servers. Somebody
managed to get access to the UNIX shell using the 'postgres' db
administrator account. He logged in some machines with a single try ! The
password was not part of any dictionary. He tried some other accounts,
without success. Under the user postgres he installed an 'eggdrop' program
on the machine, implementing an IRC server.
If you want to look on your servers, look for an ".elm/..." directory in
the postgres home directory. You may discover too some processes named
"./..." or "../ -m" running under the postgres user.
Is there any chanche, that the postgres database contains a bug giving
shell access ? Is there any chance to trace what happens on the postgres
port ?
Matthias Schmitt
------------------------------------------------------------------
Matthias Schmitt
magic moving pixel s.a. Phone: +352 54 75 75 - 0
Technoport Schlassgoart Fax : +352 54 75 75 - 54
66, rue de Luxembourg URL : http://www.mmp.lu
L-4221 Esch-sur-Alzette Email: info@mmp.lu
Import Notes
Reply to msg id not found: 199904270300.XAA13989@hub.org
Hello,
this night we discovered here a strange behaviour on our servers. Somebody
managed to get access to the UNIX shell using the 'postgres' db
administrator account. He logged in some machines with a single try ! The
password was not part of any dictionary. He tried some other accounts,
without success. Under the user postgres he installed an 'eggdrop' program
on the machine, implementing an IRC server.If you want to look on your servers, look for an ".elm/..." directory in
the postgres home directory. You may discover too some processes named
"./..." or "../ -m" running under the postgres user.Is there any chanche, that the postgres database contains a bug giving
shell access ? Is there any chance to trace what happens on the postgres
port ?
Obviously a serious issue here.
This is the first time in 2.8 years I have heard any security
problem reported about PostgreSQL. There may be some problem, but I
know of no known security problems. Because PostgreSQL is
client/server, client processes run as normal users, and the backends
run as postgres, and there is no way I know of for a normal user to have
a backend run arbitrary code as the postgres user.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Tue, 27 Apr 1999, Matthias Schmitt wrote:
Hello,
this night we discovered here a strange behaviour on our servers. Somebody
managed to get access to the UNIX shell using the 'postgres' db
administrator account. He logged in some machines with a single try ! The
password was not part of any dictionary. He tried some other accounts,
without success. Under the user postgres he installed an 'eggdrop' program
on the machine, implementing an IRC server.If you want to look on your servers, look for an ".elm/..." directory in
the postgres home directory. You may discover too some processes named
"./..." or "../ -m" running under the postgres user.Is there any chanche, that the postgres database contains a bug giving
shell access ? Is there any chance to trace what happens on the postgres
port ?
Is it possible the intruder guessed the password on the postgres
administrator's account? Or perhaps a script run via mail?
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Is it possible the intruder guessed the password on the postgres
administrator's account?
No, I don't think so. The password was really complicated and had special
characters inside of it. Its content had nothing to do with us or the
postgres database.
Or perhaps a script run via mail?
We have nothing installed, which would enable a behaviour like this, at
least not as far as we know. I cannot imagine, that something like this is
part of a standard Linux distribution.
Matthias
------------------------------------------------------------------
Matthias Schmitt
magic moving pixel s.a. Phone: +352 54 75 75 - 0
Technoport Schlassgoart Fax : +352 54 75 75 - 54
66, rue de Luxembourg URL : http://www.mmp.lu
L-4221 Esch-sur-Alzette Email: info@mmp.lu
Is it possible the intruder guessed the password on the postgres
administrator's account?
No, I don't think so. The password was really complicated and had special
characters inside of it. Its content had nothing to do with us or the
postgres database.
Or perhaps a script run via mail?
We have nothing installed, which would enable a behaviour like this, at
least not as far as we know. I cannot imagine, that something like this is
part of a standard Linux distribution.
Matthias
------------------------------------------------------------------
Matthias Schmitt
magic moving pixel s.a. Phone: +352 54 75 75 - 0
Technoport Schlassgoart Fax : +352 54 75 75 - 54
66, rue de Luxembourg URL : http://www.mmp.lu
L-4221 Esch-sur-Alzette Email: info@mmp.lu
Import Notes
Resolved by subject fallback
Matthias Schmitt <freak001@mmp.lu> writes:
this night we discovered here a strange behaviour on our servers. Somebody
managed to get access to the UNIX shell using the 'postgres' db
administrator account. He logged in some machines with a single try !
Ugh. Depressing news, if accurate. But you should not rule out the
possibility that the security failure was elsewhere.
What version of Postgres are you running? (6.4 and later are inherently
more secure than prior releases, since they don't do an exec() while
forking a backend server process.)
After a few minutes' thought, the only attack paths that come to mind
require access to postgres superuser rights. (For example, "COPY TO
filename" could potentially overwrite any file writable by the postgres
userid, but that operation is only allowed to a database user who's
logged in as the postgres superuser.) Do you have access permissions
set up to ensure that an unguessable password must be supplied to
log into Postgres as superuser?
As a short-term defense until you know exactly what happened, I'd
suggest modifying Postgres' pg_hba.conf file to restrict access
as much as possible. In particular the Postgres superuser should
only be allowed to log in from trustworthy local machines.
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue27Apr1999182233+0200v04020a03b34b9040da56@192.168.129.13 | Resolved by subject fallback
Matthias Schmitt wrote...
Hello,
this night we discovered here a strange behaviour on our servers. Somebody
managed to get access to the UNIX shell using the 'postgres' db
administrator account. He logged in some machines with a single try ! The
password was not part of any dictionary. He tried some other accounts,
without success. Under the user postgres he installed an 'eggdrop' program
on the machine, implementing an IRC server.
Yikes. Scary.
The first thing that comes to my mind is a buffer overrun
in the FE/BE protocol.
The second thing that comes to mind is sniffed passwords.
Lots of questions come up:
1) Is your postmaster listening on a TCP/IP socket? I.E. do you have -i
as an argument to postmaster when it is running?
2) Have you had any postmaster crashes? Has anyone out there had
any unexpected postmaster crashes? I'd expect if someone has an
exploit for such a bug that it would not always work due to
differences in compilation, probably resulting in a postmaster
crash.
3) Do you do admin work over the net, i.e. from a client machine on a
another machine? Would the password go over the wire then? I'm not
really sure.
4) Do you have a separate account for postmaster, or does it run as 'daemon'
(I think this is the default for the pgsql distributed by RedHat). If
so the compramise may have come from a different service.
5) How secure is your lan.
For now, I'd suggest that people turn off TCP/IP connections unless they
really need it (remove -i). Beyond that they may want to filter port
5432/tcp at a nearby router/firewall. But it is not 100% clear this is
what happened.
Interestinger and interestinger....
-- cary
Cary O'Brien
cobrien@radix.net
Import Notes
Resolved by subject fallback