[Icecast] How to troubleshoot admin auth values in url format http://admin:password at icecast.org:1234

[Philipp Schafft]

Good morning,

On Mon, 2018-09-24 at 23:49 -0400, Steve Wasiura wrote:
> Hello,
> 
> I'm asking if there is a way to do extra troubleshooting for admin auth, by
> adjusting a config parameter (i.e. loglevel), then looking at log files.

Have you check the accesslog? This would be the first place to look.


> Sometimes I can auth properly when trying to update metadata using a url
> with basic auth embedded before the server/hostname, requested from a web
> browser like google chrome.
> 
> i.e.
> http://admin:password@icecast.org:1234/admin/metadata?mode=updinfo&mount=...
> etc
> 
> Other times, I can't, and I can't figure out why not.

Note that calling this API node is only for legacy codecs like MP3 and
AAC. You should avoid using them.


Also note that this API endpoint is special. It may require you to
connect from the same source IP as the actual source you try to update.
(Details are different for different versions of Icecast.) This is due
to a flaw in those codec's design that would allow an attack on the
server without this security check.



> 1. Does admin:password in this scenario (a web browser request) need to be
> encoded to Base64, or can it be the "normal / plaintext" i.e. "admin" ?
> 
> Reading the code on Github,

Don't. Use Our official repo at:
http://git.xiph.org/?p=icecast-server.git;a=summary
or even better:
https://gitlab.xiph.org/xiph/icecast-server/tree/master



> in src/connection.c
> static int _check_pass_http
> 
> it appears it calls a method util_base64_decode, so it appears it is trying
> to decode it.
> 
> but sometimes this works from a web browser request when username:password
> is typed in plaintext (not base64encoded)
> 
> does the browser automatically encode it behind the scenes before the
> network tranmission?

It does. No need to care about it. :)


> 2. is there anyway to enable a more detailed logging level which would be
> able to echo the values submitted, to validate if they are being changed by
> the web browser during transmission?

Not directly. Also how much Icecast logs depends on it's version.


> in same code file, I see
> WARN1("Base64 decode of Authorization header \"%s\" failed", header+6); In
> which log would this appear? access or error?

error log.

> 
> Thank you.
> 3.

I hope that the above is of help for you. I feel like the same-ip check
is the relevant one as this could explain why it works sometimes.

With best regards,

-- 
Philipp.
 (Rah of PH2)