---------- Forwarded message ---------- Date: Wed, 13 Oct 1999 15:10:34 -0400 (EDT) From: Manos Megagiannis <manosat_private> To: Alfred Huger <ahat_private> Subject: Re: your mail > >1) If the WebTrends Enterprise Reporting Server is running as root. Due > >to file ownership misconfiguration, it may be possible for local users to > >gain root privileges. > > A) Do you know if the server itself is run by default as root? I seem to > remember this not being the case, althoguh I do not have the software in > front of me to test. You can run the server as root or as some other user. In order to use PAM (Pluggable Authentication Module) it has to run as root. Also they have some entry in the configuration file, that you specify what user the front end will run as, but.... the front end just interfaces to the server that runs as root anyway .... Therefore you can still do whatever you want. > B) Which files in this instance are compromisable, and why? If a local user has (or gains) uid or gid bin can gain root privileges. The WebTrends directories with the script (executed as root) are owned by user bin, group bin, and read/write/execute permissions for owner and group. Therefore someone can write a simple perl script that will be executed as root. (I could give you an exploit script if you want, but its not to difficult to figure out.) > > 2) WebTrends Enterprise Reporting Server, logs debug > >information in a world readable and writable file. The debug information > >may include user-names and passwords stored in clear text. It may be > >possible for local users to gain unauthorized access to the server as > >well as to WebTrends administration software. Local users can also modify > >that file, making the auditing mechanism unsafe. > > A) Under what circumstances does it do this? Is this failed login attempts > stored in the clear? Bungled passwords etc? If the server is running without PAM, you have to use their interface to create new users and set their passwords. In that case, by default, everything (including username and password) is stored in clear text in the file "interface.log" with read/write permissions for user, group and other. Any local user can read that file and therefore, if a WebTrends user has also an shell account on the box with the same password, that account can be compromised. Also since everybody has write access to that file, they can alter it, so the auditing purpose of that file is useless. > >3) WebTrends Enterprise Reporting Server, stores its user information in > >files with world read/write permissions. It may be possible for local > >users to gain unauthorized access to the WebTrends administration > >software, and/or create a denial of service. > > A) How do they gain access via this? Username/Password pairs stored in the > clear? > > B) I am not clear on how this leads to a DoS attack. All user information is stored in the directory "wtm_wtx/datfiles/users" in the format "username.usr". Those files are with owner/group/other read/write permissions. Any local user, can decrypt the password or even easier alter/delete the user file and therefore create a denial of service. > >4) WebTrends Enterprise Reporting Server, stores its profile information > >in files with world read/write permissions. It may be possible for local > >users to create a denial of service. > > A) How? Same as with the user files all profile information is stored in "wtm_wtx/datfiles/profiles" with owner/group/other read/write permissions. Any local user can alter/delete the profile file and therefore create a denial of service. > >5) On WebTrends Enterprise Reporting Server, the default installation has > >blank administrator password. A remote user may be able to gain > >administrative privileges to the WebTrends administration software. > > > A) Ouch, you would think they would know better. This I take it does not > actualy lead to shell access but control over the software itself from a > web interface? Thank god they do not alter the /etc/passwd. So yes you can not use this to get shell access but you can get full administrative privileges on their own software. Manos ------------------------------------------------------------------ Totally Secure, Inc. http://www.totallysecure.com Manos Megagiannis manosat_private ------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:07:34 PDT