Introduction
Like any Internet facing web site, this site is regularly probed by
hackers for any known weaknesses they can exploit. Based on my daily
review of the web server log files, most of these probes consist of
attempts to request resources that either have known exploits or can
provide information that can be used to compromise the web site's security
or integrity. These resources are typically either part of a software
application, or administrative/test files that shouldn't be deployed to a
production web site. These probes are unfortunately a normal part of doing
business or providing information on the Internet. While the probes are
frequent, most attempts are usually not successful. This site was recently
the target of a successful malicious redirect attack. Because I felt that
others might find it interesting, I decided to write up what I have
learned about the attack. To the best of my knowledge, no
personal or private information was compromised in this redirect attack.
What is a Redirect Attack
So what is a redirect attack? That is when code is inserted into a web
site with the intent of redirecting a visitor to another website. This is
done to fool a user into trusting a malicious or lower reputation page by
making them believe it is from a trusted or higher reputation
source. There are several ways to implement this type of
attack. I will not go into detail on all of them in this article. In this
specific instance the attacker accomplished the redirect by inserting a
new file into the web site and pointing search engines directly to the new
file. None of the rest of this web site was changed or affected, making
the change less obvious. The only time the redirect took place was if a
user directly requested the URL of the newly inserted file. The only way
to find the inserted file was through a search engine.
How I Was Notified
The way I learned that this web site was compromised was indirectly
through the Google Search Console. For those not familiar with this Google
tool, it is a tool that webmasters can use to help measure and optimize a
web site's search traffic and performance. The web site owner or webmaster
registers their web site with the tool by providing proof of ownership for
that site. This proof can come in several forms. Google will send a
verification code that is then placed in either a DNS TXT record for that
domain or in a file in the root of the web site. Once the site is
registered the webmaster can submit a sitemap that describes the layout of
the web site. This sitemap provides information that Google can use to
more efficiently index the web site.The search console can then provide
performance information as well as identify usability issues.
I received an email from the Google Search Console that a new owner had
been added for this site. Google routinely sends an email to notify all
site owners when site ownership changes. I knew I hadn't added any new
owners as I am the sole owner for the site in Google Search Console. By
checking the email headers of the notification email I was able to confirm
that the email was legitimately from Google. I immediately logged into the
search console and checked the web site owners listed there. I was the
only owner listed. I was going to attribute the email I received to a
software error, but wasn't comfortable with doing that just yet.
Further research revealed that there was a way to use another Google tool
called Webmaster Central that can list in detail any verification requests
to become site owner for search console. Webmaster Central did indeed show
a successful verification attempt and the addition of a new site owner in
the search console. While I had verified myself using a DNS TXT record,
the malicious owner had verified themselves using the file method of
verification. In order to successfully verify themselves using this method, they would
require access to the root directory on this web site. If so, the web site
had been compromised.
Initial Clean Up
A quick check of the root folder on this web site revealed the
verification file the malicious hacker had placed there. I immediately
deleted the new owner in search console and the verification file on this
web site. With that cleaned up, I began the investigation into how the
attacker had gained access to the site and what they were attempting to
accomplish.
At this point I need to make it clear that while I was notified by the
Google Search Console, it was this web site that was compromised and not
the Google tool. Once the web site was compromised the attacker was able
to authenticate themselves with the Google tool. It was actually the
security built into the search console that made me aware that the site
had been compromised.
Once the newly added owner and verification file had been removed I started
digging into what malicious activity the hacker had been performing. My
first stop was the web server log files. The files always have plenty of
unsuccessful attempts at retrieving non-existent URLs. This time I noticed a
URL I didn't recognize being requested successfully. The resource being
requested was inidwf.aspx. The HTTP referrer for these requests was from
baidu.com, a Chinese search engine that was indexing the site through this
aspx page. A quick check of the root folder of this web site turned up the
inidwf.aspx file. More evidence that the site was compromised. In a panic, I
quickly deleted the file. If I had been thinking more clearly I should have
saved the file so I could analyze it further. At this point I changed my web
hosting password in case it had also been compromised. I then notified the
ISP hosting my web site so they could determine if it was just my account or
a much larger breech.
Research and Discovery
Now that I could breathe a little easier I had the urge to dig a little
deeper into what the intruder was actually attempting to do on my site.
Since I had hastily deleted the evidence I couldn't just look at the aspx
page code to see what it did. I also wanted to determine exactly why they
needed site ownership in Google Search Console. I had initially assumed
(incorrectly) that they wanted access to the search console so they could
monitor the performance of their inidwf.aspx page. More on this later. And
I still needed to determine how they had gained access to the file system
on my hosted web site.
My first step in this analysis was to ensure that I wasn't somehow
deploying these extra files from my development environment. A quick check
of the folder I deploy the web site from revealed that it was clean. Then
I checked the sitemap file I deploy with the application for any
references to inidwf.aspx. It was clean as well. That led me to check the
sitemap in the search console to ensure it was the same as what I
deployed. That's when I noticed there were now two sitemaps for my web
site in search console. The first sitemap was the one that I deploy along
with this web site. The second sitemap pointed to inidwf.aspx with a
number of URL parameters that I assume directed the aspx page to return a
sitemap for Google to index. According to Google, it had indexed 1800
entries for this sitemap. I hastily deleted the extraneous sitemap. Once
again, I should have retained a copy for analysis.
This sitemap got me wondering what site was being indexed as a part of my
site. A quick Google search for inidwf.aspx turned up a number of
sites. I reviewed several of the the sites returned from my search.
All of them were legitimate eCommerce sites, except for the fact that they
had this extraneous aspx page. All of the search results referenced the
inidwf.aspx page on the legitimate site and passed in parameters with id
numbers and the compromised site's domain name. The offending page
redirected to the eCommerce site paybanks.cf. This eCommerce site has a
very low reputation, so the attacker was using legitimate sites with
higher reputations to redirect traffic to their site. This explained why
they needed access to Google Search Console (to have their bogus sitemap
indexed) and the reason for inserting inidwf.aspx on to my web site (to
provide the bogus sitemap and redirect to their shady eCommerce web site).
Outstanding Items
I'm still not certain as to how the hacker gained direct folder access to
my web site. One possibility is that my password has been compromised. If
so, changing it and enabling two factor authentication should help
mitigate that issue. Since the attack is wide spread rather than isolated
to this web site it is possible that the attacker is using an exploit that
is common among all of the affected servers. The Web hosting provider for
this site is researching log files across their hosted domains to help
determine how the intruder gained access. They have notified me that they
have deleted the injected files and are synchronizing permissions. I don't
yet have a clear answer as to how the intruder gained direct folder access
to my web site.