Ok so we did some investigating on our forum to see how vulnerable we were to this attack; Agafonov's discovery was a big help in understanding what was going on.
Let me summarize what I think i understand, pieced together from several places and from going through the code.
The attack is a multi-step attack:
FIRST, the user uploads an avatar image (or an attachment on a post), doesn't really matter, and doesn't have to be an image i don't think.
The goal here is for them simply to get their payload php script onto your server.
SECOND, they trick the forum code into INCLUDING their payload php file while it's running other php code.
This second part is the tricky part, and it's what makes some of the potential fixes suggested in this thread useless.
The original method that they use to execute the file payload was described back in november 2008, as can be seen in this thread:
http://www.simplemachines.org/community/index.php?topic=272393.20The basic idea is that the evil user tells the smf forum to INCLUDE a file from the CUSTOM theme directory (variable theme_dir). And then they bring up one of the pages on the forum that actually loads a file in the theme dir.
By setting the themedir to the file path of their malicious fake image file (with a \0 on the end of it as seen above), the malicious user actually tricks the smf forum to parse the fake image file and execute the php in it directly).
---
Now, the part that makes this a bit messy to fix is that there are NUMEROUS places in smf where a user's custom 'theme_dir' variable can be set, and numerous places where it is used.
It seems to me that most of these were fixed in earlier SMF releases.. *BUT* a few remain(!) and that is how this exploit is still occuring.
---
[the truth is that users should NEVER be allowed to customize their theme_dir -- this is a flaw in smf and should be remedied]
I'm offering some fixes we did locally, but i'm not guaranteeing this will fix all the risk -- and i hope smf people will follow up.
The first fix will prevent the Theme Picker from using custom user theme_dir variables, which should prevent this particular exploit even in users which previously modified their variable in an effort to hack your forum. This one is most important quick fix and should solve this particular exploit:
In Themes.php, FIND:
$request = db_query("
SELECT ID_THEME, variable, value
FROM {$db_prefix}themes
WHERE variable IN ('name', 'theme_url', 'theme_dir', 'images_url')" . (empty($modSettings['theme_default']) && !allowedTo('admin_forum') ? "
AND ID_THEME IN ('$knownThemes')
AND ID_THEME != 1" : '') . "
AND ID_THEME != 0
AND ADD AT THE END
AND ID_MEMBER = 0
The second fix will prevent new changes to users theme_dir variable (but not correct existing changes that evil members already set).
I'll leave it for someone else to go into more details since im running low on sleep but basically
In Profile.php, go into makeThemeChanges function
and inside both loops through $_POST['options'] and $_POST['default_options']
and add a line inside the loops saying:
if (strpos($opt,'_dir')!==FALSE || strpos($opt,'_url')!==FALSE)
continue;
---
There are 2 more things you can do:
search the smf database, the themes table
for rows where variable=theme_dir
the hits are users who have tried to use this exploit.
DELETE THESE ROWS -- after noting the filenames and userids.
now i'd say don't panic when you find entries there -- but DO go check out the files uploaded by these users (you'll see them listed in these rows), and make sure you don't find really evil php code in any of them.. those tables will also tell you which exact users uploaded the files an attempted to run exploits. then delete those attachment files.
---
hope that's at least some use -- sorry it's not explained better but we just spent a few hours on this right before we planned on sleeping, so i'm just rushing to explain what we found in time to be useful to someone.
and note that none of the instructions above will do anything to CLEAN a system that has actually been exploited by this attack by someone who put really malicious code in one of the payloads.
