One problem with using a single Docker server for a modern smuggling operation is that I end up running a bunch of web applications on different port numbers that I can’t remember. The other challenge is needing to connect to that server from a number of different methods.
I might be connecting through local ports on SSH tunnels, NeoRouter, or via a hostname.
Putting a bunch of links to the different server ports on a webpage *seemed* simple enough: just grab a basic Apache container, fire it up, and create a basic webpage full of hyperlinks. Turns out, there are several challenges with this:
- You don’t know what network you will be accessing the server from. The IP, FQDN, or hostname could be different every time you access the webpage. A hyper link to 192.168.1.211 is of no help if that IP is inaccessible to the client. This *could* be solved by using relative paths in the hyperlinks *but*…
- Apache adds a leading slash to a relative path. That means that a link “:1234″ will point to http://example.com/:1234”
- I haven’t created a web page without using a content management system in *at least* 15 years. I am just a bit behind the kids today with their hula-hoops and their rock-and-roll.
So I did what I always do when presented with a technical challenge: fall back on a piece of knowledge that spent like 30 minutes learning that one time, like 20 years ago.
A long time ago, in a galaxy far away, there used to be these crappy free web hosts like Geocities where people could make their own websites. You could do all kinds of things with Java and JavaScript, but you couldn’t do anything that ran on the web server, like CGI scripts or server-side-includes. Server side includes were important, because you could commonly used code (like the header and footer for the page) in a couple of files, and if you changed one of those files, the change would replicate over your whole site.
You could do something similar with JavaScript. You put the script that you want on every page, and tell JavaScript to load it from a single file. Like so:
<script language="JavaSscript" src="header.js"/>
In the header.js file, I would put in a ton of document.write statements to force the client browser to write out the HTML of the head and body sections of the web page. I called this horrible technique “client-side includes”:
document.write('<body bgcolor="000000">');
For the current challenge, I just have to rewrite the URL for each hyperlink, based on some variables on the page:
< script language="JavaScript" >
document.write('< a href="' + window.location.protocol + '//' + window.location.hostname + ':8989' +
window.location.pathname + '"> Sonarr < / a > </script >
Sorry for some of the weird spacing, convincing WordPress to mark up JavaScript without actually executing it is kind of fiddly. The code examples look better here.
The solution works most of the time. I like to browse for torrents with a browser that blocks ads and JavaScript, so I have to enable JS for that tab, and then browse in that tab with caution. Sonarr, Radarr, and the like all rely heavily on JavaScript, so I prefer to use Brave’s shields wherever possible.
chrizzle23.com 