Fake login screen disrupts audio stream - Solved

[WHVW]

Hi All:

While listening to an audio stream, the stie throws up a useless login screen:

Screenshot from 2019-03-03 18-33-23.png

It serves no purpose except to disrupt the stream; "x-ing" out of it allows you to start the stream again without entering anything. Cursory examination reveals the following:

Code: Select all

{
  "log": {
    "version": "1.1",
    "creator": {
      "name": "Firefox",
      "version": "60.0.2"
    },
    "browser": {
      "name": "Firefox",
      "version": "60.0.2"
    },
    "pages": [
      {
        "startedDateTime": "2019-03-03T17:15:01.140-05:00",
        "id": "page_1",
        "title": "tunein.streamguys1.com/secure-msnbc-free?key=b4c898dfa24d35ad9c32a9c",
        "pageTimings": {
          "onContentLoad": 37908,
          "onLoad": 38035
        }
      }
    ],
    "entries": [
      {
        "pageref": "page_1",
        "startedDateTime": "2019-03-03T17:15:01.140-05:00",
        "request": {
          "bodySize": 0,
          "method": "GET",
          "url": "http://tunein.streamguys1.com/secure-msnbc-free?key=b4c898dfa24d35ad9c32a9c",
          "httpVersion": "HTTP/1.0",
          "headers": [
            {
              "name": "Host",
              "value": "tunein.streamguys1.com"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"
            },
            {
              "name": "Accept",
              "value": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
            },
            {
              "name": "Accept-Language",
              "value": "en-GB,en;q=0.5"
            },
            {
              "name": "Accept-Encoding",
              "value": "gzip, deflate"
            },
            {
              "name": "DNT",
              "value": "1"
            },
            {
              "name": "Connection",
              "value": "keep-alive"
            },
            {
              "name": "Upgrade-Insecure-Requests",
              "value": "1"
            }
          ],
          "cookies": [],
          "queryString": [
            {
              "name": "key",
              "value": "b4c898dfa24d35ad9c32a9c"
            }
          ],
          "headersSize": 375
        },
        "response": {
          "status": 401,
          "statusText": "Authentication Required",
          "httpVersion": "HTTP/1.0",
          "headers": [
            {
              "name": "Server",
              "value": "Icecast 2.4.3"
            },
            {
              "name": "Date",
              "value": "Sun, 03 Mar 2019 22:15:01 GMT"
            },
            {
              "name": "Content-Type",
              "value": "text/plain; charset=utf-8"
            },
            {
              "name": "WWW-Authenticate",
              "value": "Basic realm=\"Icecast2 Server\""
            },
            {
              "name": "Cache-Control",
              "value": "no-cache"
            },
            {
              "name": "Expires",
              "value": "Mon, 26 Jul 1997 05:00:00 GMT"
            },
            {
              "name": "Pragma",
              "value": "no-cache"
            }
          ],
          "cookies": [],
          "content": {
            "mimeType": "text/plain; charset=utf-8",
            "size": 26,
            "text": "You need to authenticate\r\n"
          },
          "redirectURL": "",
          "headersSize": 273,
          "bodySize": 299
        },
        "cache": {},
        "timings": {
          "blocked": 0,
          "dns": 111,
          "connect": 41,
          "ssl": 0,
          "send": 0,
          "wait": 186,
          "receive": 0
        },
        "time": 338,
        "_securityState": "insecure",
        "serverIPAddress": "204.93.137.116",
        "connection": "80"
      }
    ]
  }
}

I have isolated its URL and experimented on it with umatrix, but I cannot block it. There must be some way.

Any ideas?

[WharfRat]

If you can get the address of that popup maybe an iptable rule e.g., sudo iptables -A INPUT -s 208.190.213.54 -j DROP will prevent it.

[WHVW]

WharfRat:

I tried:

sudo iptables -A INPUT -s http://tunein.streamguys1.com/secure-ms ... 5ad9c32a9c -j DROP
-and-
sudo iptables -A INPUT -s http://tunein.streamguys1.com/secure-msnbc-free?+ -j DROP

but it kept returning an "invalid mask" error. If I use the straight IP address, it would block other stuff the site needs to run. Of course, it is quite possible that I have made a mistake in the command syntax.

What do you think?

[WharfRat]

You need the IP address or address range. From your message it seems to lead up to 204.93.137.116

If you check whois 204.93.137.116 it returns.

Code: Select all

NetRange:       204.93.128.0 - 204.93.255.255
CIDR:           204.93.128.0/17

So try sudo iptables -A INPUT -s 204.93.128.0/17 -j DROP

If you need to clear the input table sudo iptables -F INPUT

To check if you get any drops sudo watch -d iptables -L -nv

[WHVW]

WharfRat:

I can't block the whole IP address, since it contains other (necessary) elements which will break the site if absent. The "box" is at:

tunein.streamguys1.com/secure-msnbc-free?key=b4c898dfa24d35ad9c32a9c

Could a block be made that specific? What is in red should probably be a wild card, since it will most likely change from time to time.

The IP address (http://204.93.137.116/) returns a menu which, among other things, includes the feed, it will be interesting to see if it (the block box) appears here, also. Most likely, it will.

[WharfRat]

Clear the table with sudo iptables -F INPUT then try sudo iptables -A INPUT -m string --algo kmp --from 0 --to 140 --string 'free' -j DROP

[WHVW]

WharfRat:

That breaks the site, both directly and indirectly accessed.

But the box,

tunein.streamguys1.com/secure-msnbc-free?key=1d447ab19dd30b3c93bbb54aa0810a2a9

still gets through. That thing is like an internet battering ram.

[WharfRat]

You can try sudo iptables -A INPUT -m string --algo kmp --to 90 --string 'Authentication' -j DROP

This will probably kill the whole thing too though.

[WHVW]

WharfRat:

Your latest command line fix stops the box when I summon it by its address. When I load the site, it plays, so although I haven't tested it by waiting to see what happens when they throw the box, I feel confident that this will work. That's really cool. Thank you.

This opens up a larger question: when sites send this and other, similar interruptions, they completely cripple your browser. You can't click on another tab; if you click on O.K. (as opposed to the "X") the box bounces back. If you are fast enough to click on another tab before it does, it will cancel that tab and return you to the tab from whose site it came. In other words, they have commandeered your browser, controlling what you do and how you do it.

It would seem to me that this should not be. Is there/shouldn't there be a way to order the command hierarchy so that your commands will always override those of an external source?

later

[WharfRat]

That's one of those dialogue boxes that forces a reply before it allows you to continue.

I don't think there's any workaround besides changing its properties which in not in your control.

Hopefully this latest iptable rule will at least solve your dilemma.

[WHVW]

WharfRat:

I am going to run that site as an "acid test" of your iptable rule, but based on my preliminary tests, I'd bet the farm that it will work.

As far as that dialogue box goes, that seems like a HUGE security risk and a made-to-order attack vector for the malware crowd; just attach a request for the download of some script and away it goes! (this threat is probably worse for Winderz folks...).

You obviously know much more about this stuff than I, which highlights the reality when it sinks in: it is disturbing to realise that we are stuck with this annoyance/vulnerability and that there isn't any fix contained within the thousands of "about:config" lines. And, for that matter, that no one has written an add-on to fix it. I don't know how to write code, but that would be an easy fix.

Allowing websites to stop your browser cold until you do what they want seems sheer idiocy to me, (especially in this "threatware" age). Why would browsers be designed that way in the first place?

Oh, sorry for the rant, and thanks again.

P.S. Well. the iptables rule works on my 17.1 machine, but not on my 19.1 machine, where it breaks the site. Both of these machines are only 32 bit. Arrgh!