Session Hijacking, Cookie-Stealing WordPress Malware Spotted

Session Hijacking, Cookie-Stealing WordPress Malware Spotted

Researchers have identified a strain of cookie stealing malware injected into a legitimate JavaScript file, that masquerades as a WordPress core domai

Exclusive: Dutch Cops on AlphaBay ‘Refugees’
Microsoft Culls Secret Flash Whitelist After Google Points Out Its Insecurity
Amazon Employees Given ‘Broad Access’ to Personal Alexa Info

Researchers have identified a strain of cookie stealing malware injected into a legitimate JavaScript file, that masquerades as a WordPress core domain.

Cesar Anjos, a security analyst at Sucuri, a firm that specializes in WordPress security, came across the malware during an incident response investigation and described it in a blog post Tuesday.

Anjos says it appears attackers used typosquatting, or URL hijacking, to craft the phony domain, code.wordprssapi[.]com. Typosquatting is a technique that usually relies on users making typographical errors when inputting URLs into a web browser. In this case the fake site is designed to look like a legitimate WordPress domain so it doesn’t appear out of place in the code.

The researcher said it appeared attackers injected malware into the bottom of a legitimate WordPress JavaScript file designed to reroute sensitive information, such as cookies, to the fake domain.

Denis Sinegubko, a senior malware researcher at Sucuri, told Threatpost Wednesday that it’s likely an attacker took advantage of another vulnerability in WordPress to inject the obfuscated code in the first place.

“Modern attacks rarely use one specific vulnerability. They usually scan for multiple known vulnerabilities (mostly in third-party themes and plugins) and then exploit whatever they find,” Sinegubko said.

Anjos points out that in addition to appearing at the bottom of an actual WordPress JavaScript file – wp-includes/js/hoverIntent[.]min[.]js – the code also uses a typical obfuscation pattern, eval(function(p,a,c,k,e,d). The function, commonly used in JavaScript libraries and scripts, tightly packs code that’s later executed when the page loads.

After Anjos decoded the obfuscated code, he saw the malicious – and now offline – wordprssapi site.

In this case Anjos says a conditional statement hidden at the top of the code excludes cookies from user agents from search engine crawlers. That “extra mile” by the attacker, Anjos says, helps weeds out cookie information from crawlers and bots and “ensures that the data being sent to attackers is more likely to immediately be usable.”

Once it’s been determined the data – in this case a users’ cookies – are valuable, a script sends it to the malicious site (code.wordprssapi[.]com) so it can be siphoned up and used by attackers, Anjos says.

By stealing a user’s cookies, through what’s essentially a session hijacking attack, an attacker can pretend to be that user and perform any actions the user has permission to perform. At least until those permissions are revoked; something that’s done after a period of inactivity for many types of online accounts, including WordPress.

The site that URL is mimicking, code.wordpressapi[.]com, isn’t even a legitimate site, the researcher points out. But in this case, that doesn’t matter; the fact that it includes the word “WordPress” is enough to make it look like it belongs, Anjos says; that’s what tricks users.

“By purchasing a domain closely resembling a legitimate website platform or service, some webmasters might overlook this in their code and assume it is an official WordPress domain (which it is not),” Anjos wrote.

Sinegubko is a bit puzzled when it comes to who may have been behind the malicious site.

“No clue,” Sinegubko said when asked Wednesday, “As always, WHOIS data is ‘privacy protected,’ the IP (45.32.137.126) points to vultr[.]com network (not a typical choice for hackers especially with the Windows IIS/8.5 server).”

In addition to ensuring they have clean code, webmasters should double check sites to ensure they’re not sending sensitive data, like cookies or passwords, to a third party, Anjos says.

“This is something that all webmasters should be aware of when they are auditing their own code. Be careful and always check that a domain is legitimate, especially if it is involved in collecting or sending information to a third-party site,” the researcher wrote.

Go to Source

COMMENTS