$matches = array();
preg_match("/^Get(.+)Repository$/", "GetFooBarRepository", $matches);
var_dump($matches);

array(2) {
[0] => string(19) “GetFooBarRepository”
[1] => string(6) “FooBar”
}

And there is nothing wrong with that. Except for the fact that numeric indexes are not always easy to work with. And it does not look all that clean in the code itself. SO last week my LD pointed out the fact that the likes using name based indexes for the matched patterns. And this is pretty sweet. I have seen it before but never bothered to adopt it myself. And the result looks like

$matches = array();
preg_match("/^Get(?.+)Repository$/", "GetFooBarRepository", $matches);
var_dump($matches);

array(3) {
[0] => string(19) “GetFooBarRepository”
‘repositoryName’ => string(6) “FooBar”
[1] => string(6) “FooBar”
}

And i have to say. It looks a lot cleaner. So i added this to my bag of tricks. And will be using it from now on.

$url = reset($file->getPaths());

So how can that throw an error like “Only variables should be passed by reference” you might ask? Well as it turns out to be. PHP functions don’t like arguments returned from another function. As with this case. The ->getPaths() method holds a reference to the returned array. Which it shouldn’t but that’s another thing.

So i guess from now i will doing the thing below. Or check for references beforehand!

$paths = $file->getPaths();
$url = reset($paths);

But i wanted to check out the GIT support available in Zend Studio 9. And hit a problem pretty quickly. But i will describe that below. First i will create a local clone of my git project.

$ git clone ssh://[somehost]/~/git/project.git

To test if everything is working i do a test commit. If that succeeds if push it out to the remote master.

$ cd project.git
$ touch TEST
$ git commit
$ git push origin master

So that works fine. Now time to see how Zen Studio handles this. To create a project i use the Create from Git option. And select the local checkout i just created. This will read the whole repository configuration. And you are basically done from here. But as i mentioned earlier, i had some difficulties getting things running smoothly. I discovered that when it was time to push changes to the master repository.

When i used the Push to Upstream option. I was greeted by a login panel that seemed to have selected the correct SSH key and user to perform the login. But when i typed the password, it just kept asking for the password. Again and again. Hmm. That sucks! The password was correct. I tried with a newly created key. No luck either. The last thing i tried was updating to a nightly build of Egit found here. But this offered no solution either.

After reading a couple of complaints i found this bug report for the EGit eclipse plugin. The thread contains a solution for the login issue i was having. Gotta love Google!

Apparently the problem has to do with the encryption algorithm used to create the SSH keys. In this case the EGit plugin (which uses Jsch to do the SSH communication) was having problems with AES encrypted keys. And to solve the problem the Jsch library should be replaced with a newer version to make things work again.

So lets download this JSch library and update it manually. The library (JSch v 0.1.46) can be found here.

$ cd ZendStudio9
$ find . -name ‘*jsch*’ -type f

Found it plugins/com.jcraft.jsch_0.1.41.v201101211617.jar. So let’s try to update that.

$ cp plugins/com.jcraft.jsch_0.1.41.v201101211617.jar plugins/com.jcraft.jsch_0.1.41.v201101211617.jar.backup
$ wget http://sourceforge.net/projects/jsch/files/jsch.jar/0.1.46/jsch-0.1.46.jar/download
$ mv jsch-0.1.46.jar plugins/com.jcraft.jsch_0.1.41.v201101211617.jar

After restarting ZS everything worked fine again. Another problem solved! Thanks to the guys who posted in the EGit bug thread. Some good community Karma here! Time for other things. Hope it helps!

I picked up the phone. And the guy (Amoria Bond) on the other end immediately started his sales pitch. O shit another one of those nasty recruiters. So after listening to him for a few seconds i quickly interrupted him. Told him i was not interested in a new job at all. And that he was a jerk and extremely unprofessional for calling me at the office. Completely unaware (or maybe intentionally?) what impact this might have if for instance my manager picks up the phone. Besides it’s just plain rude.

Now don’t get me wrong. It’s not a rant for nothing. I don’t hate recruiters. And have worked with some professional ones in the past. I’ve always enjoyed communicating with linda-lotte while she was still working for Recruit4it. And the guys at Starapple are OK as well. But this guy today really pissed me off with his aggressive unmannered approach. It’s a shame i didn’t catch his name while i was in rant mode. But please don’t ever call me again.

Update:

It seems to be some form of new tactic to call developers in the office where they work. This happened a couple of times more after this post. So this is for the next recruiter that calls me in the office. I’ll personally come over and kick your ass!!

With the email came a small excerpt of a IRC channel log. I recognized the node. So SSH’ed into that specific node. And used netstat to check for any strange connections. A connection on port 20 to the C&C node of the botnet. Thats not good.

$ netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 xxx.xxx.xxx.xx:20 69.162.80.62:20 ESTABLISHED

In the email from NCSC it was mentioned to look for files called wp-rss3.php. But a search for this file did not return any hits. Hmmm. And i still had no idea which site it concerned. Since a couple were running on this particular node. The only thing certain. It’s WordPress related. So i started searching for recent WordPress compromises. And found a lot of hits on Google for the timThumb and wps3slider plugins. But checking the log files for these plugins revealed nothing. And for some weird reason i just cleaned up the log partition a couple of days before. So not much luck there.

Some more Googling told me to do a search on the WordPress installs for the PHP function base64_decode(). O well. Lets give it a try. Some suspicious files did show up instantly.

$ find . -type f -exec grep -l ‘base64_decode’ {} \;
./uploads/2010/06/wp-rss4.php (source)
./uploads/2011/05/alienee.php (source)
./plugins/wps3slider/temp/34e3a3a74f6e2d0f236bdd3ba70c0c03.php (source)
./plugins/wps3slider/temp/cf2cdb3ad3249b9692de07290f16f287.php (encoded) (decoded)
./plugins/wps3slider/temp/771b821c974131c67e34c83d8d2db725.php (encoded) (decoded)
./plugins/wps3slider/temp/2b3753ea4769084f2e571737b695b03a.php (encoded) (decoded)
./plugins/wps3slider/temp/7228f168d9692eafeafc54dbc3a1ab49.php (encoded) (decoded)
./plugins/wps3slider/uploads/1.php (source)
/var/tmp/dc.pl (encoded) (decoded)

Interesting. A quick look at the files showed that most of them were obfuscated. But not all. Two of the files were IRC bots written in PHP. At this moment i couldn’t resist but crack a little smile. But its also a reminder of how fragile the web really is. I quickly moved the files out of the way. And rebooted the machine. When it came back online i monitored all connections for a while. But the connection to the C&C node was not restored. So i informed NCSC. And went back to bed!

The WordPress admin should have kept the sites up to date. Lesson learned i hope! of course i could not resist to come back to it later. And so i did. I started by searching the Apache log files for wp-rss4.php. And found a couple of instances where this file was directly called. From a total of 4 different IP addresses.

69.162.80.62

This is the IP address of the C&C server.

186.241.16.25
201.8.237.18
201.8.226.109

These IP addresses are all originating from Brasil. No further information is available at this moment. After that i started poking around the trojans / IRC bots found earlier. And as mentioned earlier. There were two bots installed on the server, One was running. The other wasn’t. This is configuration snippet from both bots.

The first bot. And the one i was informed about.

var $config = array("server"=>"antesedepois.servegame.com",^M
                     "port"=>20,^M
                     "pass"=>"depois",^M
                     "prefix"=>"depois",^M
                     "maxrand"=>8,^M
                     "chan"=>"#depoiswp",^M
                     "key"=>"",^M
                     "modes"=>"+iB-x",^M
                     "password"=>"depois",^M
                     "trigger"=>".",^M
                     "hostauth"=>"*" // * for any hostname^M

And the second one

var $config = array("server"=>"58.225.75.155",
                     "port"=>9999,
                     "pass"=>"",
                     "prefix"=>"animal",
                     "maxrand"=>8,
                     "chan"=>"#animal",
                     "key"=>"",
                     "modes"=>"+iB-x",
                     "password"=>"oishi",
                     "trigger"=>".",
                     "hostauth"=>"*!*@The.Black.Cat" // * for any hostname
                     );

Notice the ^M characters at the end. Seems like somebody is using windows. So now we have login details for two C&C servers. Why not take a look.

$ ircii
/server antesedepois.servegame.com:20

Some standard IRC stuff

*** Connecting to port 20 of server antesedepois.servegame.com
*** Welcome to the Internet Relay Chat Network, root (from IRCPRIVATE)
*** /etc/irc/script/local V0.5 for Debian finished. Welcome to ircII.
*** If you have not already done so, please read the new user information with /HELP NEWUSER
*** Your host is IRCPRIVATE, running version 1.2.1546
*** This server was created jan 27 2012 at 06: 29:02 HodB (Serial # 00-00-00)
*** channel modes available abdefghijklmnopqrstuvwxyzACEFIKLMOPT
*** IRCX
*** There are 6 users and 362 invisible on 1 servers
*** 7 channels have been formed
*** This server has 368 clients and 0 servers connected
*** Current local users: 368 Max: 989
*** Current global users: 368 Max: 989
*** MOTD Not Present

So let’s check the channels on this thing

/list

*** Channel Users Topic
*** #depoiswp 360 Entrou = Ban :)
*** #grmteam 6
*** #depoisSca 4 Entrou = Ban :)
*** #depoisSca 4 Entrou = Ban :)
*** #depoisVul 6 Entrou = Ban :)
*** #rfi 3
*** #sql 1

I entered all of the channels and waited for a while. But no activity took place. The only really interested channel is #depoiswp. This is the channel where all the bots connect. At the time i logged in there were about 360 of them available. I immediately recognized the log excerpt send to me by the NCSC.

*** Topic for #depoiswp: Entrou = Ban :)
*** #depoiswp SYSTEM 1327945185
(#depoiswp/#depoiswp) Entrou = Ban :)
*** [A]depois88802849 (~depois48170648@68.233.238.XX) has joined channel #depoiswp
*** #depoiswp 1327653297
*** [A]depois13436992 (~depois92951214@212.227.114.XX) has joined channel #depoiswp
*** [A]depois18833547 (~depois69088341@184.154.130.XX) has joined channel #depoiswp
*** [A]depois80116634 (~depois13242297@213.251.189.XXX) has joined channel #depoiswp
*** [A]depois31855907 (~depois23946193@82.85.28.XXX) has joined channel #depoiswp
*** [A]depois25458508 (~depois64120008@87.106.214.XX) has joined channel #depoiswp
*** [A]depois17803105 (~depois55004207@74.208.16.XX) has joined channel #depoiswp
*** [A]depois96800217 (~depois89042073@174.121.216.XXX) has joined channel #depoiswp
*** [A]depois17108432 (~depois51961332@209.68.1.XXX) has joined channel #depoiswp
*** [A]depois95432403 (~depois13925479@209.68.1.XXX) has joined channel #depoiswp
*** [A]depois96515275 (~depois10767943@195.74.38.XXX) has joined channel #depoiswp
*** [A]depois73596561 (~depois90562179@69.89.31.XXX) has joined channel #depoiswp
*** [A]depois85357227 (~depois31697723@64.191.115.XX) has joined channel #depoiswp
*** [A]depois07993697 (~depois40240585@79.96.128.XX) has joined channel #depoiswp
*** [A]depois97441253 (~depois19633359@193.189.74.XX) has joined channel #depoiswp
*** [A]depois76843389 (~depois55419325@176.9.34.XXX) has joined channel #depoiswp
*** [I]depois16679788 (~depois28004829@213.171.218.XXX) has joined channel #depoiswp
*** [A]depois88178285 (~depois05296405@74.220.215.XXX) has joined channel #depoiswp

<[A]depois16231776> [Attack Finalizado!]: 1749605 MB enviados / Pacotes enviados: 14580 MB/s
<[I]depois60130568> [Attack Finalizado!]: 75 MB enviados / Pacotes enviados: 1 MB/s
<[I]depois48664304> [Attack Finalizado!]: 75 MB enviados / Pacotes enviados: 1 MB/s
<[I]depois65415449> [Attack Finalizado!]: 75 MB enviados / Pacotes enviados: 1 MB/s
<[I]depois11325010> [Attack Finalizado!]: 75 MB enviados / Pacotes enviados: 1 MB/s
*** [A]depois40994506 (~depois72760562@79.98.28.XX) has joined channel #depoiswp
<[A]depois07568398> [Attack Finalizado!]: 2187317 MB enviados / Pacotes enviados: 18228 MB/s
<[A]depois55402758> [Attack Finalizado!]: 11425 MB enviados / Pacotes enviados: 95 MB/s
*** [A]depois03383512 (~depois52457929@74.220.215.XX) has joined channel #depoiswp
<[A]depois37064023> [Attack Finalizado!]: 1264043 MB enviados / Pacotes enviados: 10534 MB/s
<[A]depois69234369> [Attack Finalizado!]: 2205504 MB enviados / Pacotes enviados: 18379 MB/s
*** [A]depois74911768 (~depois04730096@74.220.215.XX) has joined channel #depoiswp
*** Signoff: [A]depois31575043 (Connection reset by peer)
<[I]depois17710498> [Attack Finalizado!]: 81 MB enviados / Pacotes enviados: 1 MB/s
<[I]depois28464134> [Attack Finalizado!]: 81 MB enviados / Pacotes enviados: 1 MB/s

Thats fine and all. I disconnected shortly after that. I really have no reason to be poking around there now do i ;) Besides who want to interfere with an ongoing investigation. So poking around the files a bit more didnot reveal all that information.Except for the fact that besides a IRC bot a backdoor was also installed in the form of a perl script dc.pl installed in /var/tmp. So who knows. The server might be rooted at this point.

I spend some more time on decoding the bot and trojan contents. And posted them on pastebin if you are interested. The server is going to be decommissioned soon. So i am not going to pay much more attention to it.

1.php and b2dabd0e2c42b55fabf741bcac29f857.php

Web Shell by boff

2b3753ea4769084f2e571737b695b03a.php

This file was base64 encoded but once decoded reveled to be a simple script by v0pCr3w and nob0dyCr3w to run system commands on the server. Also included was a simple upload form.

34e3a3a74f6e2d0f236bdd3ba70c0c03.php

c99 injector v1

771b821c974131c67e34c83d8d2db725.php

This script was rot13 and base64 encoded and was trying to cleanup after the hacker. And install a second back door.

7228f168d9692eafeafc54dbc3a1ab49.php and cce0a37ffc138a8908da05977639bed1.php

Again rot13 and base64 encoded.But this script contained something that looks like a control panel. The page title was ‘Hacked by Sherif #oishi @ ALLnet’

alienee.php

Still working on this one

cf2cdb3ad3249b9692de07290f16f287.php and ded3244749701c4eb5a29b959ad56736.php

These files contained a second bot that was connecting to a whole different server. Probably exploited by another crew?

dc.pl

This Perl backdoor was created by one of the IRC bot scripts. And was hiding in /var/tmp after creation.

And some links i found useful while working on this issue.

http://eromang.zataz.com/2012/01/08/gangbang-mytijn-org-malware-spreader-down/

http://www.madirish.net/content/hookworm-stealth-php-backdoor
http://markmaunder.com/2011/08/01/zero-day-vulnerability-in-many-wordpress-themes/

Last week a critical bug was discovered in PHP. Which affects versions 5.3.9 and 5.2.17. The bug could be exploited to run arbitrary code on a remote PHP system. So upgrade your systems. And of course Stefan Esser popped up with some wise words :)… O well i still think the guy does great work.

More info about the issue can be found on packetstorm (CVE-2012-0830)

session adoption & session fixation

The problem exists because the current session module does not validate the session id that comes in from a cookie. This means uninitialized session id’s can be passed by the client. This happens due to the fact that browsers overwrite cookie if multiple cookies are send per request.
Some people would say this is solvable by implementing session_regenerate_id(). But this is not the case.

Because session fixation can be used to take over control of web applications. Validation is required when multiple cookies are send per request. When multiple cookie are send with a request. Browsers send multiple cookies without domain / path information. This way it’s impossible to tell which cookie belongs to which domain.

So how do we fix this?

There is some userland code that does offer the ability to validate session data. But this has not been widely adopted by other developers.

Code that adds the session ID as a validation key:

session_destory();
session_regenerate_id();
$_SESSION['valid_id'] = session_id();

And the code to check if the session was properly initialized:

if ($_SESSION['valid_id'] !== session_id()) {
  die('Invalid use of session ID');
}

Thank god the internal developer know this. And are working to fix this. For the past days there has been an interesting discussion going on on the internals list. About applying a patch that will fix this. The patch will add some new php.ini features and a new method validate_id() for the session save handler. Hopefully this will be available in version 5.4.

To not break BC strict_mode will be disabled by default. But can be enabled by setting the following setting in php.ini. When enabled uninitialized session ID will be discarded.

session.use_strict_mode=0

To prevent a DoS instead of session fixation. An new feature has been added that deletes possible malicious cookies that prevent new session ID.

session.safe_session_cookie=1

You can read more about session fixation and the upcoming patch on the PHP-Wiki

abbywinters.com (NSFW) is one of the largest and most ethical, highly rated, well designed, and successful erotic websites in the world today. abbywinters.com is the WINNER of the AVN 2011 Awards for Best Membership site!

And we are looking to hire a new talented webdeveloper to expand our small team. What would you think about joining our small Agile team of highly qualified professionals?

You will be creating sexy, exiting and game changing experiences for the web, work for one of the industry leaders. And just be part of an awesome company. Some of the jobs key elements are:

• Implementing development projects
• Leading informal mentoring during day-to-day work
• Contribute to design of development projects
• Track, reduce, and prevent technical debt in Web Development projects

Motivated by principles of social responsibility, we deliver provocative media by embracing imagination, creativity and emerging technologies. Our models, customers and business partners are inspired by our fervid passion.

Our experienced staff use state-of-the-art content production facilities to produce 10 shoots a week from concept to finished art, utilizing the most advanced digital capture, post production and delivery systems in the world.

You will be working directly with our Web Dev Manager, Lead developer and colleagues in the web dev team. We need each individual to contribute for us to continue as a pioneer in our industry.

If you posses a “Can do” attitude. Would like to work in the center of Amsterdam. And are able to identify your self in the criteria below. You might want to head over to our career portal for a more detailed description.

Technical competencies – Required

• High level of skill with PHP 5
• High level of skill with Object Oriented Programming
• High level of skill with HTML/CSS
• High level of skill with JavaScript
• High level of skill with Internet Applications
• Moderate level of skill with Unit Testing and Test Driven Design
• Moderate level of skill with MySQL
• Moderate level of skill with Windows XP operating system
• Experience with the GNU/Linux operating system
• Competent with Revision Control systems (Subversion)
• Bachelor of Science in Computer Science, or equivalent experience
• Zend Certified Engineer, or equivalent experience
• At least 5 years experience in Web Application Development

Technical competencies – Desired

• Moderate level of skill with the Apache HTTP server
• Good understanding of the Model-View-Controller pattern
• Good understanding of the ActiveRecord Object-Relational-Mapping pattern
• Familiarity with Agile software development practices (Scrum)
• E-commerce
• Agile development experience

Intrigued by the fact that my 32-bit Ubuntu installation did not suffer from the same issue. I started to read the PHP5 changelog for Ubuntu.

CFLAGS=”-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64″ ./configure

But this has a negative side effect. Namely PHP running 50% slower then it should be. And to my surprise Ubuntu applies the CFLAGS above when compiling PHP5 for a 32-bit platform. So that would mean PHP on Ubuntu is always running 50% slower? Well according to this is should be the case.

I downloaded php-5.3.8 from php.net and compiled two versions. One with the CFLAGS set for large files. And one normal without any changes. After that i downloaded the benchmark script from php-benchmark-script.com. And did a couple of runs on each of the two installs. The results are stunning.

PHP-5.3.8 compiled with large file support:

test_math : 4.414 sec.
test_stringmanipulation : 4.968 sec.
test_loops : 3.529 sec.
test_ifelse : 2.344 sec.
————————————–
Total time: : 15.255 sec.

PHP-5.3.8 compiled without large file support:

test_math : 2.274 sec.
test_stringmanipulation : 2.286 sec.
test_loops : 1.619 sec.
test_ifelse : 1.228 sec.
————————————–
Total time: : 7.407 sec.

That’s pretty much a 50% speed decrease. One more thing i tried is adding the ‘AC_SYS_LARGEFILE’ macro to configure.in and rebuild the configure script. But this had no effect at all.

$ cd php-5.3.8
$ vi configure.in (add AC_SYS_LARGEFILE somewhere)
$ export PHP_AUTOCONF=/usr/share/autoconf2.59
$ ./buildconf –force

I then tried two things. First i build without the CFLAGS. But this didn’t seem to do much. Then i used the same configure script with the CFLAGS for large file support. But there was no speed increase measurable.

So why would Ubuntu have made the choice to compile PHP with the large file support on a 32-bit platform? Are there really that much developers that work on large files in web / cli applications written in PHP? Enough to sacrifice a 50% speed decrease?

I don’t really know the answer to that. But i will do my large file processing on 64-bit machines. And will compile PHP from scratch from now on. Until i have upgraded my aging hardware.

Importer found (0) files to import!

Hmmm. That’s not right. So i had a look at the code behind the importer. Which basically is a loop using a DirectoryIterator object. And some var_dump calls revealed the issue. For some reason ->isFile() was returning (false) for regular files. WTF! Let’s test that on the command line.

$ php -r “var_dump(is_file(‘/some/file.ext’));”;
bool(false)

Ok so we have an issue here. How big are these files really. A inspection revealed they are all over 2GB. Maybe some 32 bit issue? As the platform the code is running on is a 32 bit server. So i asked my colleagues, Googled a bit and read through php.net. To find out that there is an issue with PHP and files larger then 2GB.

https://bugs.php.net/bug.php?id=27792
https://bugs.php.net/bug.php?id=48886
http://nl.php.net/manual/en/function.filesize.php

Those however all seem related to filesize. The filesize function manual page even has a note about it. Maybe it’s related?

Note: Because PHP’s integer type is signed and many platforms use 32bit integers, filesize() may return unexpected results for files which are larger than 2GB. For files between 2GB and 4GB in size this can usually be overcome by using sprintf(“%u”, filesize($file)).

But i can’t apply that patch on a production server. So i came up with a simple solution for now. I extended the DirectoryIterator class and have overwritten the isFile method. Which works for now (don’t think this will work on windows).

Class MyDirectoryIterator extends DirectoryIterator {
	public function isFile() {
		return (integer) exec("[ -f {$this->getPathname()} ] && echo 1 || echo 0");
	}
}

Convinced it was a 32 bit issue. I came home later that day. And wanted to try it out on my own desktop. That is a 32 bit system and runs Ubuntu 11.04. To my surprise the result was different then i expected.

$ php -r “var_dump(is_file(‘/some/file.ext’));”;
bool(true)

I used the same files as before. And tested some more big files. But the result was the same. Weird. Let’s try some other 32 bit machines.

Ubuntu 11.04: bool(true)

CentOS release 5.6 (Final): bool(false)
Debian 6.0.2 (squeeze): bool(false)

Only my desktop at home seems to have a good result. Ubuntu must have some patch somewhere to fix this issue? To confirm i compiled PHP 5.3.8 from source. And did the same test again on Ubuntu 11.04. And this time it was (false).

$ php -r “var_dump(is_file(‘/some/file.ext’));”;
bool(false)

I am not really in the mood to search the Ubuntu changelog. And for now the work around will do. But i really would like to know what patch is applied to resolve the issue.

[ update ]

While applying the patch for the is_file issue. I was confronted with the fact that way more function calls cause issues. So while waiting for PHP to get patched i had to create some workarounds for the time being.

Getting the filesize:

(integer) exec("stat -c%s {$file->getFilename()}");

Calculate a MD5 checksum:

$md5 = exec("md5sum {$file->getFilename()}");
$expl = explode('\t', $md5);
return (string) $expl[0];

Calculate the CRC32 checksum:

$hash = exec("cksum {$this->path}");
$expl = explode(' ', $hash);
return $expl[0];

Get the modified time:

$stat = explode('.', exec("stat -c%y {$this->path}"));
$timestamp = strtotime($stat[0]);
return $timestamp;

Hopefully that will do for now. On a side note the issue is solvable by setting certain CFLAGS when compiling PHP. I have no idea what the impact of that will be on the PHP binary. But it does seem to solve the issue. Not sure how one would apply that when PHP is installed from the distro’s repository though.

CFLAGS=”-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64″ ./configure