Securing boyet.com, part 1: static sites

Sounds simple, right? After all, I’ve babbled on about how to secure your web sites this past few months, both for AWS and Azure, so it should be a piece of cake for boyet.com. Right?

Well, unfortunately, no.

Thing is, I bought boyet.com 20 years ago in November, and, after using TDMWeb (which was owned by the publisher/editor of The Delphi Magazine, for which I wrote algorithm articles) as hosting for a while, I switched to GoDaddy. And then proceeded to mess things up by taking advantage of some of GoDaddy’s weirder capabilities in their shared Windows hosting. In essence, boyet.com as a website became two distinct properties: www.boyet.com and boyet.com/. The former one was my static-page blog that I transitioned in August 2008 to a ASP.NET version using Graffiti CMS, and that new version became the latter name.

Ohhh-kayyy, so what? Problem is that GoDaddy, although it does support HTTPS and SSL for sites hosted there, requires you to buy the certificate from them and to use their premium hosting plan to boot. Megabucks. Time then to switch over to Azure was my first thought, but then I would have to disentangle the old static site and the ASP.NET-hosted one. Time to put it on the back burner: it all sounded tedious.

And then an old friend, Jeroen Pluimers, tweeted this at me:

@JMBucknall https://t.co/WGM77kDSQL in an anonymous Chrome window gets to the site; in a regular Chrome tab goes to [dodgy pharmacy site] Somehow that persisted as a 301 in the browser cache. Clearing the cache and retrying solved the issue.

— Jeroen Pluimers (@jpluimers) August 21, 2018

Even worse:

Some pages in that directory return content@touch('web.config',-1,-1); @touch('default.php',-1,-1);

Shortly after that, they redirect to the pharmacy site.

This happened at http://www.boyet.com/FixedArticles/QualitySoftware.html as well. pic.twitter.com/VRqMrhnXpi

— Jeroen Pluimers (@jpluimers) August 21, 2018

WTF was going on? I had noticed once or twice the weird “@touch” stuff appear, but generally it was at the same time as an HTTP Error 500 (Internal Server Error) that GoDaddy’s server was sending back and that seemed more important. The ASP.NET blog was fine, it was just the static-page site that was showing these problems. Time for investigation, and the results were not pretty.

I’m not going to go into all the tedious experiments and brain farts I suffered through in order to work out what had happened, but in essence my web.config file had been “hacked” and a couple of PHP scripts had been added to the root of my static site. By who? Don’t know. Maybe another web site on the shared hosting had been hacked (there have been stories about that in the past, I now discover) which then propagated to other domains on the same host. Maybe some automated process at GoDaddy. Who knows.

Although the site is static, it does have a web.config in order to declare a mimeMap to configure the woff file extension for a font I use. That web.config had been changed by the HackNinja to include this code:

    <rewrite>
      <rules>
        <rule name="Protect files and directories from prying eyes" stopProcessing="false">
          <match url="^(.*)$" ignoreCase="true" />
          <conditions logicalGrouping="MatchAny">
            <add input="{HTTP_USER_AGENT}" pattern="(bing|google|yahoo|msn|aol)" ignoreCase="true" />
            <add input="{HTTP_REFERER}" pattern="(bing|google|yahoo|msn|aol)" ignoreCase="true" />
          </conditions>
          <action type="Rewrite" url="default.php" appendQueryString="false" />
        </rule>
      </rules>
    </rewrite> 

In essence, the code says “if the HTTP user agent includes those well-known web names, or the HTTP referrer does, route to and execute default.php instead”.

Not only that, but two PHP files had been added to the root. One was the code-mentioned default.php and the other, cleaner.php. The latter’s content was the @touch code that Jeroen was talking about in his second tweet. The former? Ready? A single line, no line feeds, that looked like this:

<?php ${"G\x4cO\x42\x41L\x53"}["\x6d\x6bm\x6a\x6ag\x76\x6ft"]="m";[…]?>

It’s 7KB long, that line, hence the ellipsis. No recognizable code, it’s all obfuscated and encoded. Yeah, right. Looks totally normal and legit, right? If I deleted the code and the files, usually they’d come back after a few hours or days.

Needless to say this prompted me to do some major fixing. First, I bought firstboyet.com and secondboyet.com, and hosted them on AWS. The first domain was for two sets of content: my TurboPower blog I used to write (using FrontPage, natch) until I bought boyet.com in November 1998 (and a couple of years after that, too), and the initial set of blog posts I made on my new site until I switched to using CityDesk in July 2003. The other domain was for the static CityDesk site that has been up on boyet.com since then. Since both comprised static pages – no ASP.NET in sight – I could easily make them secure on AWS.

Once that was done, I added a permanent redirection rule in the web.config on the GoDaddy hosting for the static site, and stripped everything else out (and deleted all of the other files for the site as well: basically the folder now just contains the config file).

  <system.webServer>
    <rewrite>
      <rules>
        <rule name="redirect to secondboyet" enabled="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTP_HOST}" negate="false" pattern="^(www\.)?boyet\.com$" ignoreCase="true" />
          </conditions>
          <action type="Redirect" url="https://secondboyet.com/{R:1}" appendQueryString="true" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite> 
  </system.webServer>

The redirection rules essentially says, “if someone tries to get to boyet.com/foo/bar.html, permanently send them to secondboyet.com/foo/bar.html; ditto for any link to somewhere on www.boyet.com”. Just because I could, I changed all links in my GraffitiCMS blog to the static site to point to the new domain.

Since then, I’ve been monitoring via FTP the contents of the sites on GoDaddy and the hack problem seems to have gone away. Fine by me.

Now, though, it’s time to migrate this ASP.NET blog to Azure. More permanent redirects later (although more probably some DNS changes) and I’ll finally wave bye-bye to GoDaddy hosting.

  Loading links to posts on similar topics...