Hacked again

Hacked again

Received an email from Google today:

  • Hacking suspected: http://rxkinetics.net/
  • Unfortunately, it appears that your site has been hacked.

What does it mean to have pages marked with the hacked site type “URL injection” in Search Console?

This means a hacker has created new pages on your site, often containing spammy words or links.

Typically, hackers modify your site in one of these ways:

  • By gaining access to an insecure directory on your server. For example, you may have inadvertently left a directory with open permissions. Nope, no anonymous FTP is allowed.
  • By exploiting a vulnerability in software running on your site, such as a content management system. For example, you might be running an older, insecure version of WordPress. Nope, don’t have WordPress or any content management system.
  • By hacking third-party plugins that you use on your site, such as visitor counters. Nope, no 3rd party plugins on this site.

None of the above are true, I believe they discerned my password yet again with a brute force attack.

List of alerts from Google:
Google_analytics_messages

It looks like they’ve been attacking my web site since March when it was defaced:
Page_Not_Found_Errors

Apparently they were searching for pages they could target. They searched for links common on most web sites, e.g. “Cart” and “FAQ” and “Feed back”. None of which exist on this web site.

I removed the spammy content, and changed my password yet again. I plan on changing password every week now. I wonder how long it takes Google to remove my site from their hacked sites list (sigh).

LunarPages support response was helpful, “we are planning to upgrade the Operating System that is used by your shared windows environment within the next months that will ensure that your Operating System is updated and will add a new layer of protection on your website security.” And they scanned my site for malware:
Scan_results

I’m beginning to think all this hassle just isn’t worth it anymore. It’s nearly impossible to get an email through anymore. I’ve resorted to using Gmail as my mail server, but even then many of my emails replies are rejected. My ListServ is a joke, the only requests are from spammers and scammers pushing the 3-P’s (Pills, porn and poker).

The terrorists have won.
Kim_Jong

Hacked!

Got home from a long night at work and checked my email to find this friendly FYI:

Hi Rick,
This is Steve ####.
Hope life is treating you well
FYI- your site rxkinetics.net coming up with “something unexpected” on home page.
Regards,
Steve

So I went to rxkinetics.net and found this lovely NSFW message (without the scambling).

The graffiti

Wow, hacked! Just like the big boys, I feel so special now .

Really? I think these losers would have something better to do than vandalize my insignificant little corner of the internet.

I sent a support ticket to Lunarpages, then discovered that typing in the full url bypassed the graffiti:
http://rxkinetics.net/default.aspx

It was a long night and I was dead tired, so I emailed Steve back and went to sleep.

About noon I woke up and checked my email. There was no reply from Lunarpages, so I got out of bed and dug into the web site files.

There were four suspicious .asp files on the site. They stuck out like a sore thumb because I don’t use .asp files on this web site:

  • pageface.asp
  • sin.asp
  • crx.asp
  • default.asp

None of the correct files were changed. I deleted the four rogue files and the site went back to normal.

Then I changed my ftp password and asked Lunarpages if there was anything else I needed to do. Well, it’s been over eight hours since I started the support ticket and I’ve yet to receive a response from Lunarpages. I’m pretty disappointed, because up to this point, they’ve always been quick to reply and provide help.

All of this makes me wonder if this was an inside job from a disgruntled employee at Lunarpages.

Fun with ASP.NET

I’ve been trying off and on for 5 months to get the AJAX toolkit to run on my ASP.NET WebApp site. The web host only supports ASP.NET 2.0, so finding relevant information on an 8 year old technology is challenging.

I first tried adding a reference to the DLL in an aspx page:

<%@ Register Assembly="AjaxControlToolkit, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>

The page crashed on load with this Parser Error Message: “Could not load file or assembly ‘AjaxControlToolkit’ or one of its dependencies. The system cannot find the file specified.”

I contacted the web host who stated “There is only ASP.NET 2.0 AJAX Extensions installed on the server. AJAX toolkit is not installed on the server.”

I had to ask if there was any possibility that the AJAX toolkit could be installed. The web host replied “There are two work arounds for this, first that you manually upload the DLL files into /cgi-bin folder and include the path of the DLL’s into your code and then let us know we will setup full permissions on /cgi-bin folder. Second work-around is to setup permissions for your IIS worker process user to Temporary .net folder please tell us the version of the .net you are using and we will setup the permissions accordingly.”

Since I had no idea what the second work-around was, I manually uploaded the DLL file to the cgi-bin directory.

Same error message “The system cannot find the file specified.” After some research, I added the path info to web.config:



Same error. Next, I added tagPrefix to controls:



Same error. Decided to switch tactics and go back to registering the assembly on the aspx page instead of web.config.

<%@ Register Assembly="AjaxControlToolkit, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>

Same error, more research. Decided to add Src tag:

<%@ Register Assembly="AjaxControlToolkit, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Src="cgi-bin/AjaxControlToolkit.dll" %>

New error: The directive is missing a ‘tagprefix’ attribute. Added it:

<%@ Register Assembly="AjaxControlToolkit, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Src="cgi-bin/AjaxControlToolkit.dll" TagPrefix="toolkit" %>

New error: The directive is missing a ‘tagname’ attribute. Added it:

<%@ Register Assembly="AjaxControlToolkit, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Src="~cgi-bin/AjaxControlToolkit.dll" TagPrefix="toolkit" TagName="ajxtool" %>

New error: The ‘assembly’ attribute is not supported on this directive when a ‘tagname’ attribute is present. More research, took out the src and tagname tags:

<%@ Register Assembly="AjaxControlToolkit, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" TagPrefix="toolkit" %>

New error, The directive is missing a ‘namespace’ attribute. Added Namespace:

<%@ Register Assembly="AjaxControlToolkit, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" TagPrefix="toolkit" Namespace="AjaxControlToolkit" %>

New error: The located assembly’s manifest definition does not match the assembly reference. Aha, this was new. I double checked the version of the DLL I downloaded from Microsoft. It was version 1.0.20229.20821, not 1.0.61025.0. Finally, this worked:

<%@ Register Assembly="AjaxControlToolkit, Version=1.0.20229.20821, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" TagPrefix="toolkit" Namespace="AjaxControlToolkit" %>

So, the ASP “Parser Error” was leading me down the wrong path. The file wasn’t missing at all, it was an incorrect version match. After all that research, I knew it had to be some basic, fundamental thing I was doing wrong (it almost always is).

I went back to web.config and made the following changes.










Finally, what a relief. And all that work just to get a modal popup dialog, sheesh!