Does this explanation of a website malware fix make sense?
September 5, 2017 7:18 AM   Subscribe

Our website had the problem where if you search for it on Google, the results description on the Google search results page referred to Cialis and Viagra links. Clicking on these results takes you successfully to our website, and no Cialis or Viagra junk is visible on the actual site. The problem was only visible from the Google search results page. Can someone tell me if this explanation of the problem and solution makes any sense. (It seems to me that this description is certainly describing a problem, but I'm not sure it's related to the symptoms above.)

"php.backdoor.webshell_gen.059 removed

Backdoors are server-side malicious scripts which are intended to perpetrate malicious acccess to the server. The typical example of such backdoors are various File Managers, Web Shells, tools for bypassing admin login or various one-purpose scripts allowing the attacker to upload and run another type of malicious scripts. The payload is PHP based, thus intended for server-side use and the payload is executed directly on the server, while the site is loaded. Only the payload result (such as Web Shell environment) is visible in the browser, not the malicious code itself. It's very common, that backdoors don't have any visible signs in the site code and it's impossible to detect them by accessing the infected site from outside. Server level analysis is necessary in case of infection by this type of malware."
posted by lockedroomguy to Technology (7 answers total) 3 users marked this as a favorite
I've seen similar malware in poorly run / poorly managed wordpress sites (I was brought in to disinfect them). The malware would look at who was requesting the page. If it was a regular user, the malware wouldn't run- but if it was google's spider, it would generate a bunch of viagra spam to try and raise the SEO value of some pathetic scammer's site.

It sounds like you were hit by something similar- in the one I was working on, it was embedded in template code that wasn't upgraded even when the wordpress core was, which left a lingering vulnerability that was very hard to expunge.
posted by jenkinsEar at 7:24 AM on September 5, 2017 [2 favorites]

Presenting different content depending on whether the user is a real user or a search engine crawler is called "cloaking". It's a common malware tactic.
posted by allegedly at 7:38 AM on September 5, 2017

sorry--not to threadsit:

Yes--the description I gave is as described by jenkinsEar and allegedly. But is the quoted text in my question talking about cloaking? It seems like it's talking about a generic backdoor to the site.
posted by lockedroomguy at 7:51 AM on September 5, 2017

Oh, I see what you're asking.

The explanation is kind of hard to parse - it is talking about a generic backdoor. The explanation says nothing about the symptoms, but inserting that kind of spam content is certainly one thing that a backdoor would be used for. If you were asking for an explanation of why the spam shows up on Google but not on the site, the writer is definitely explaining the wrong thing.

Removing the backdoor is a necessary first step in the solution, since the site is vulnerable as long as it's there. Depending on what they do to remove it, it may or may not also remove the spam content. If they just delete the backdoor it wouldn't undo the changes that were made using the backdoor. If they restore from a backup or something, then it may.
posted by allegedly at 8:29 AM on September 5, 2017

I'm trying to parse this:
The payload is PHP based, thus intended for server-side use and the payload is executed directly on the server, while the site is loaded. Only the payload result (such as Web Shell environment) is visible in the browser, not the malicious code itself.
When I've seen this exploit in the wild, I've been able to see what Google sees by using Lynx. Because Lynx doesn't have a JavaScript execution environment, it sees the HTML served up. The exploit was fooling the person viewing the site in a modern GUI browser because the browser ran JavaScript that patched up the document and made it look like the original.

So depending on how the exploit ran, removing it might have fixed the site (ie: the exploit was a plug-in, removing it means you're clean), or, as allegedly says, it might have altered other files on the site, and so the spam is still being served.
posted by straw at 10:01 AM on September 5, 2017

I'm not particularly familiar with the state of the arms race today, but cloaking can be done either way. Client-side tricks try to make some clients rewrite the content while others don't. Server-side tricks send back different content depending on who is asking. (There are also other categories, like invisible content that search engines treat as part of the page. Think white-on-white text, although it's usually more advanced than that.)

PHP runs on the server-side, so that's what is being described here. The part about "such as the Web Shell environment" is talking about the user interface of the backdoor itself, rather than the spam content that was put in using the backdoor.
posted by allegedly at 10:25 AM on September 5, 2017

If the backdoor is PHP run server-side it could use anything to authenticate & trigger access to the malware's webshell interface. A specific username, password, source IP address, message Subject line, hash value of an uploaded image; any of these could be set as the trigger. And no hint of the malware would be visible on the client end until it was triggered. Unless & until you meet the triggering condition there's no way to detect the malware except by auditing the PHP source.
posted by scalefree at 5:48 PM on September 5, 2017

« Older Movie recommendations for 3 yo, not scary   |   Ways to save - the out of work with no pay... Newer »

You are not logged in, either login or create an account to post comments