Re: FW: APC UPS PowerChute PLUS exploit...

[hedrick () Astro Dyer Vanderbilt Edu (Andre M. Hedrick)]

WRT "PowerChute" and "WebAgent",

Words from "Ted Ives", APCC's software production manager of "PC" and "WA",
there is no way for TCP access.  PowerChute is not capable of doing
network sharing protocols.  I know this for a fact from conversations with
Ted and Ken A., senior unix programmer.  They use the UDP access through a
SNMP port that can not be disclosed.  As for granting of TCP access, you
are required to run a remote webserver with "WebAgent" overlaid, somehow,
to broadcast UPS status from "PowerChute" to that "remote webserver".

Thus IMHO, there is no way for you to easily punch a hole in that security
method, due the difficulty is maintaining a UDP connection as an unlisted
manager.  Since the service port is below 2000, you run into the super
user status limits.

On Wed, 12 Aug 1998, Russ Crawford wrote:

> Andre,
>
> I subscribe to the BUGTRAQ listserv.  When I saw this message, I thought of
> you and the software you developed to support APC devices under Linux.

FYI, this refers to "apcupsd", which is becoming the world standard for
APC UPS management under Linux and soon all other UNIXes.

http://www.dyer.vanderbilt.edu/server/apcupsd/

> What do you think of this?  How big a problem is this?
>
> As an aside, I haven't installed Linux since I am hardware deficient.  The
> more I read about security issues with Linux and @Home, I am VERY reluctant
> to use Linux.
>
> I would appreciate any thoughts on how to secure a Linux box attached to
> @Home.

As for @Home cable modems, unless you can block and hack the SNMP trap
password, they have the power to block/limit/monitor your packet usage.

Hmmmmmmmmm...........rings of big brother...........

This is claim to prevent the establishment of a full class A network
via a firewall and packet sorting with your own DHCP.

> Thanks in advance,
>
> Russ
>
> PS: How are the squirrels doing?
>
> ----------
> From:         Peter Radcliffe
> Sent:         Tuesday, April 14, 1998 3:22 PM
> To:   BUGTRAQ () netspace org
> Subject:      Re: APC UPS PowerChute PLUS exploit...
>
> Rick Perry <perry () NEWS VILL EDU> writes:
> > I believe that the powerchute software will not listen on the net if you
> > have the following in powerchute.ini
> >
> > [ Network ]
> >  UseTCP = NO
> >
> > I didn't yet try your exploit, but with UseTCP set to NO this machine
> doesn't
> > show up in the list of remote ups's when using the powerchute admin
> interface
> > from another machine on the same subnet.
>
> [All my observations are from PowerChute Plus for Unix, v4.2.2
>  on Solaris 2.6]
>
> This means that anyone on the local machine who has a copy of the
> powerchute
> client can talk to the daemon.
>
> When UseTCP is set to YES it seems that the server only listens to network
> connections, if it is set to NO then it listens with local (unix domain ?)
> sockets.
> These seem to be in /tmp and world accessable.
>
> As a random test user on my machine I can talk to the daemon using a copy
> of
> the client, with a minimal config file and all owned by the test user.

Change the permissions that it runs under.

> The installation directory of powerchute is only readable by root.
>
> I have a BackUPS and was able to alter the (unreadable to the user)
> system powerchute.ini file. With this you could set the machine to shut
> itself
> down when powerchute is started ...
> With a SmartUPS it would be trivial to shut the UPS down right there and
> then. You can probably also shut down a BackUPS with the supplied tools
> (I don't weant to do this right now for obviousa reasons).

No you can not.......the 940-0020B cable requires a linefail to be
present.  Next you are required to drive the DTR HI.  The simple signal
protocol is very limited.  If you drive the DTR HI with the UPS plugged
into the wall and do not push the TEST toggle, you can not kill it
regardless.

If you are using the 940-0095A/C PnP cable, same results but based on the
status of RTS.

> There are also IMO lesser, but still stupid and important, issue of /tmp
> files opened unsafely (in the client and the server).
>
> All of the programs that are directly called have a TMPDIR enviroment
> variable that is set in a wrapper script (along with the location of the
> code PWRCHUTE):
>
> I created a tmp directory (only r/w by root and my staff group) in the
> installation directory and have changed the line
> > TMPDIR=/tmp
> to
> > TMPDIR=$PWRCHUTE/tmp
> in the files powerchute, upsd and xpowerchute in the installation
> directory.
> The server appears to create the pipes happily, but the client won't
> connect to the server even though a truss of _cpwrchute (the binary
> for the text client) shows it appears to use the new tmp dir and tries to
> talk to the server.
> > From powerchute.err:
> 04/14/98 16:02:44 Server: unable to verify alertConnection
> 04/14/98 16:02:52 fifo read failure Invalid argument.
>
> While looking for other instances of /tmp hardcoded I found such gems as:
> >   grep Santa /etc/perms/inst > /tmp/what_os.tmp 2>/dev/null
> from what_os.sh but the calling of this unsafe code seems to not be done
> (commented out function calls).
>
> The pager script (dialpager.sh) has:
> > tmpfile=/tmp/$$.page
>
> The mailer script (mailer.sh) does rm -f on filenames that are passed to
> it as command line options.
>
> I'm sure there are far more possible explits than this ...
> Don't run PowerChute, it seems.
>
> Anyone know of a good replacement for use with an APC BackUPS ?
> :(

Yes, my package, when the ports are final......... Solaris i386 is near
complete.  This would allow the first case of UPS sharing with different
flavors of unix.

> \pir
>
> --
> pir               pir () pir net      pir () shore net      pir () leftbank com

Cheers,
Andre Hedrick