[MUSIC PLAYING]
Hi, I'm Maile Ohye, hoping to provide guidance on the next
step of recovering a hacked site--
identify the vulnerability.
Thus far, you've quarantined your site, verified ownership
of your site in Webmaster Tools, and, most recently,
overcame one of the major hurdles in recovery--
assessing the damage.
In doing so, you were able to estimate the extent of the
damage caused by the cybercriminal, as well as
understand her intent.
The goal of this video is for you to now identify the
possible vulnerability, the root cause, that allowed the
cybercriminal initial entry to your site.
Identifying the initial vulnerability is
an important step.
If we don't recognize and correct the root cause during
the recovery process, it's highly likely that even if
your site's content is restored, the cybercriminal,
or someone else, could strike again.
It's also possible that there are multiple
independent hacks in place.
Finding and fixing one of them does not mean that you should
stop searching for others.
We'll cover some of the common ways that sites become
vulnerable, such as a virus-infected administrator
system, weak or re-used passwords, out-of-date
software, and permissive coding practices.
Hopefully, by understanding these common weaknesses,
you'll be able to understand how the hacker
broke into your site.
Like the prior step, assess the damage, several actions in
this video require technical skill, such as file system
access to the server, running commands in the terminal, and
viewing database records and source code.
If these tasks seem too technical, you may want to
review an earlier step, contact your hoster, and build
a support network.
Let's start by discussing the first possibility of a
virus-infected administrator's computer.
This is just one of the many vulnerabilities that may have
allowed the cybercriminal entry to your site.
On an administrator's virus-infected computer, the
hacker may have installed spyware to record the admin's
keystrokes.
Once the administrator typed their username and password to
log into the site, their login credentials were passed to the
cybercriminal for future entry.
This enabled the cybercriminal to easily access your site.
To check for viruses on administrator systems, we
recommend that owners of hacked sites run several
reputable Anti-Virus scanners, or AV scanners, on every
computer used by the administrator to
log into the site.
Since new malware infections are constantly being designed
to evade scanners, this action, while quite helpful,
is still by no means a foolproof
method of virus detection.
Furthermore, AV scanners may also report false positives,
so running several scanners can provide more data points
to determine whether a vulnerability actually exists.
In addition to running AV scanners on administrators'
devices, we also recommend scanning both your web server,
and, if possible, the devices used to update or post to the
site, just to be safe.
If the AV scanner detects spyware, a virus, Trojan
horse, or any suspicious program, that may be the
vulnerability which allowed your site to be initially
compromised.
But to further investigate whether a virus-infected
administrator system is the culprit, let's take a look at
the site's server logs.
In the logs, check for unusual activity by the administrator
who owns the infected computer.
Similar investigation likely occurred for you in the last
step, assess the damage.
It's possible that log files have been altered by the
hacker, making this harder to diagnose.
But if not, correlating the administrator's username with
suspicious commands in the log file is further evidence that
a virus on an administrator's system caused the site to be
vulnerable.
While investigating the log files, let's introduce a
second potential vulnerability--
weak or re-used passwords.
Cracking a weak password can be relatively easy for
cybercriminals.
And by doing so, it gives them direct access to your server.
On the other hand, strong passwords help
prevent such abuse.
Strong passwords have a combination of letters and
numbers, punctuation, no words or slang that might be found
in a dictionary, and are far more difficult to crack.
However, when passwords, even if they are strong passwords,
are re-used on various applications, it only takes
one security breach on one application for a hacker to
find the login and password, then attempt
to re-use it elsewhere.
To investigate if weak or re-used passwords may be the
problem, in the server log, check for undesirable
activity, such as multiple login attempts for an
administrator or an administrator making
unexpected commands.
Make note of when the suspicious activity occurred
because understanding when the hack first took place helps
determine what backups may still be clean.
The third potential vulnerability, and one of the
most common, is when software installed on your server, the
operating system, content management system, blogging
platform, applications, or plug-ins, is out of date.
Why is out-of-date software potentially harmful?
Well, one way that software can become out of date is when
the current version contains a security vulnerability.
If you have such out-of-date software installed on your
site, then your site, not just the software, now has a
security vulnerability.
Most software companies release a patch, or a new
version of their software, when a security issue is
discovered.
While this makes it imperative for existing users to upgrade,
unfortunately, not all the users, in this case, site
owners, are aware of the security advisory.
The vulnerable software remains on their site and is
exploited by a cybercriminal.
If you recognize your site is running outdated software,
that might be the root cause of your hack.
By researching the outdated software version, you may find
results detailing a security advisory.
If so, the possibility that outdated software caused your
site to be vulnerable is quite likely.
One important aside I'd like to mention--
as a best practice, always aim to keep your server's software
up to date, regardless of whether outdated software
resulted in a vulnerability issue this time.
The last vulnerability exploited by hackers I'd like
to cover is permissive coding practices, such as open
redirects and SQL injections.
Permissive coding practices provide cybercriminals an open
door to your site.
By exploiting lenient code, the hacker is able to perform
many harmful actions.
One example of permissive coding is open redirects.
Open redirects are coded with the intention for the URL
structure to allow the addition of another URL, so
users can reach a useful file or web page on a site.
However, hackers can abuse open redirects by adding their
spamming or malware page to the site's open redirect.
Now URLs that look like a legitimate page on a reputable
site actually utilize open redirects on the good site to
bring users to the spammy content--
or, even worse, malware or phishing pages.
If your site is abused by open redirects, you likely noticed
the message in Webmaster Tools provided example URLs that
included open redirects to an undesirable location.
This type of hacking is a vulnerability that doesn't
even require that the cybercriminal have access to
your server.
But identifying the cause of an open redirect means
understanding why the configuration
exists on your site.
Open redirects may be completely unused in your
site's design, but just a feature in your software
allowed by default, and then exploited by spammers.
Or, perhaps your code should have explicitly disabled the
potential vulnerability by
prohibiting off-domain redirects.
Or perhaps the site should have signed the redirect so
that only those with the properly hashed URLs and the
cryptographic signature could be redirected.
The final permissive coding practice that leaves your site
vulnerable to hackers is SQL injection.
If your site uses a database, and especially if you are
infected with the malware type SQL injection, it's very
possible that your site was compromised by a hacker adding
rogue commands to user input fields
executed by your database.
SQL injections update records in your database with unwanted
spam or malware content, or they dump valuable data to
output for the hacker.
In diagnosing the root cause of a SQL injection, you'll
need an in-depth understanding of your site's source code.
Look for suspicious content in the database, such as
otherwise regular text fields that now
show iframes or scripts.
For the suspicious values, check that the user input is
validated and properly escaped and that input is strongly
typed so that values may be cast as integers or strings,
but not executed as code.
If you notice permissive coding practices affecting
your database, SQL injection may be a root cause
vulnerability on your site.
To further detect the cause of SQL injections, as well as
gather more details when identifying vulnerabilities on
your site, a common question is--
should I run a vulnerability scanner?
The answer, of course, is that it's up to you.
Please be aware that vulnerability scanners differ
from anti-virus scanners.
Vulnerability scanners can be far more invasive and have
greater potential to cause unwanted damage to your site.
Please follow all directions, such as backing up your site,
before running the scanner.
Once you're able to determine the vulnerability, it's time
to move to the next step--
clean and maintain your site.
[MUSIC PLAYING]