Do you keep all of your website software (including third-party themes, plugins, and components) up to date? You should! We always recommend this to our clients and readers. Applying updates quickly will make sure that you replace any vulnerable code as soon as the security patch is released. However, this isn’t the only reason to keep your website software as fresh as possible.
Recently our incident response team had a case in which a website was redirecting users to an external domain. Ad pop-ups were displayed, and some were obviously malicious. For example, below is this Comcast tech support scam pop-up that tried to block a web browser and asked to call their number.
Flexytalk Widget Plugin
The version of the plugin we were analyzing was more than a year old and it had this iFrame in the FlexyTalk_Widget.php file:
<iframe src=“http://panel.flexytalk[.]com/account/pluginlogin/‘.$usr.’/'.$pwd .'/1" width="100%" height="100%" style="min-height:850px; width:100%" frameborder=0 ></iframe>
The plugin stores and sends the password in plain text, but that’s not the main problem. The real problem is the fact that via the iFrame, the parked domain can be used to inject payloads into unsuspecting websites, redirecting visitors and presenting them with pop-ups like the one above.
Behind the scenes, the plugin also makes requests to another flexytalk[.]com URL:
$response= curl2("http://panel.flexytalk[.]com/plugin/FlexyID?usr=".$username ."&psw=".$password); log_me($response);
Now that the domain name no longer belongs to the developer, the results of such requests are unpredictable. Best case, they’ll break some plugin functionality. Worst case, the new domain owner will steal the credentials (there are still many people who reuse their passwords across all systems) and, depending on the quality of the plugin code, may inject malware into web pages or compromise the server.
The plugin also used a hosted script on flexytalk[.]net, which also expired more than a year ago and was re-registered by a different person who parked it on another domain parking service.
$htmlCode="<script id='ftcontent' data-flexytalk=".$widget_id." ".$datadept. ">var script = document.createElement('script');script.src = ('https:' == document.location.protocol ? 'https:' : 'http:') + '//www.flexytalk[.]net/app/v3/js/flexytalk.js';document.getElementsByTagName('head') .appendChild(script);
Domainers in Action
This Flexytalk plugin was severely affected by the expiry of both domain names it used for its operation. Interesting that the .net and the .com domains were re-registered by different people a year ago and that they independently decided to park the domains.
Domain Name: flexytalk[.]com Registrant Name: wenjie chen Creation Date: 2015-09-30T18:03:17Z IP: 22.214.171.124 Domain Name: flexytalk[.]net Registrant Name: Milen Radumilo Creation date: 2015-07-09T18:03:41Z IP: 126.96.36.199
If you doubt that the domains now belong to professional domainers, just check how many domains these two own:
- Wenjie Chen (and the email address) is associated with ~4,884 domains
- Milen Radumilo is associated with ~100,000+ domains
You can imagine how many expired domains have similar behavior – ads, pop-ups, redirects. For example, the server with IP 188.8.131.52 (where flexytalk[.]net is parked now) is also used by about 75 thousand other parked websites. The name servers of this domain parking service (PARKINGCREW[.]NET) are used by over a million domains.
Flexytalk Widget Gets New Name
What happened to the plugin? It turns out that even after the expiry of the domain names, the plugin is still being developed and updated. But they changed the name and here’s the explanation from their changelog:
IMPORTANT INFORMATION: All IM accounts change to email@example.com (instead of xyz@flexytalk[.]im)
The update points your script to our new FrescoChat servers
Due to operational problems, we’ve changed our name to FRESCOCHAT”
According to the plugin repository, this happened 16 months ago. They changed the plugin name and servers but left the same flexytalk-widget plugin id so that users of the old versions of the plugin could be notified about the new versions and easily update them. Three versions with the new domain names have been released since then. Still, some webmasters refused to update the plugin – which is really strange – because it’s a live chat widget and no one needs a live chat that doesn’t work (and it didn’t work since they changed their servers 16 months ago).
Lessons Learned From This Case
Expired domains of third-party components and services that you may be using on your site can be a security problem for you and your site visitors.
There are many good reasons to keep everything up to date and get rid of unsupported legacy software. A possible dependency of legacy code on expired domains that might have changed hands since then is just one of them.
When choosing third-party software for your site (CMS, themes, plugins, components), consider whether the developers will be able to support it long term. Be wary if the software is an interface to services provided on the developer’s own domain or any other third-party domains. Try to imagine what could happen if that developer goes out of business and either stops supporting the software or sells it along with the domain name. What happens if the developer’s site gets hacked? In all these scenarios, your own site may be at risk of experiencing redirects, unwanted ads, malware injections, data theft, and server compromises.
- Install software only from reputable developers.
- Remove everything that is not critical for your site functionality.
- Get rid of all unsupported software.
- Keep everything else up to date.
- Regularly scan your site for broken links and remove references to no longer existing sites.
Very insightful Krasimir, thank you 🙂
Thanks, I am glad you liked the post 😀
Thank you, very helpful. Sometimes however I am not sure if a plugin is OK or not after it has not been updated for a longer period. Mostly I suspect and remove them from sites that clients ask me to maintain. But for example Limit Login Attempts has not been updates for 4 years now, but still is delivered standard with WordPress. Apparently the programming remains unhackable.
However, I am not able to distinguish between scripts that can remain as they are and others that need fixing (no programming experience). Is there some sort of guideline or reference? Thanks in advance
Generally I would recommend updating plugins if you see that they are outdated, if a plugin has not been updated by its author for a very long time then it might be best to remove it as the author has most likely abandoned it. We have seen some plugins being sold and the new authors adding malware. My main concern is that if a plugin is abandoned and a new vulnerability is found in it there would be nobody to patch it.
Comments are closed.