Peter Butler

Sorry to hear that happened.

I agree, an extra warning would be good, and I’ll work on getting that put in, along with a few other updates to the plugin.

Undoing is possible, and I’ve given it some thought in the past, but I just havent had the time, as it’s not an insignificant amount of work. Where do you put the backup files? How long do you leave them there? Then there’s an interface required to restore them. Keep in mind that they’re vulnerable (thats why we updated them!), so leaving them on the server at all is a risk.

I think a better solution might be to, when clicking the “update” button, point out that there’s no undo available, and urge them to take a backup right then, just in case.

Lastly – if you can give me some insight into what exactly broke (a theme? Plugin? Which specifically?), I can hopefully update the plugin to avoid the issue in the future.

Hey Mike –

Thanks for the heads up! I think what’s going on here is that hackers are scanning the .org plugin repository for any plugin containing a string that matches timthumb (which that file contains, for scanning purposes).

So – the hackers notice this, and they just add it to their list of plugins they think *might* be vulnerable, then start hitting it.

I dont anticipate there’s any way this presents a real threat (other than annoyance, or extra server load), but I’m certainly open to ideas on how it might – OR ideas on how to prevent hackers from trying to hit htis file, even if it’s futile.

Ah. Valid points Amanda. I’ll get to work.

Thanks!

Hey Amanda –

Great points! I think these could (and maybe should) both be implemented, but I want to understand the reasoning behind them.

My first instinct was to say that these features don’t have much utility, because if a vulnerable version of timthumb is showing up, it’s because you’re there, installing a plugin or a theme. However – that implies that you’re always going to have the discipline to go and run the scanner after every timy ou install a plugin (or log in within a reasonable timeframe, so you’ll be alerted by the scan running on a cron). I guess that’s not always the case – and I suppose there are situations where a client, or non-technical user is installing a theme or plugin (not a great idea, but I’m sure it happens).

Anyway – I’d love to hear the use case you’re trying to solve, but I think it probably is worth adding those features. I’ll try to get to that sometime this week.

Thanks!

Just to be clear, we all agree with AITPro. There was never an argument about whether or not pages should be accessible from outside the plugin.

You’re right, there should probably be a nonce on the scan link. I’ll get that put in.

Interesting stuff in that search. Lesson learned: Make sure your files are not directly accessible, even if they seem harmless!

I’ve just submitted an update to the plugin – hopefully it will be reviewed/released shortly.

Thanks!

Ah. Makes sense. I’ll definitely get those pages locked down – regardless of whether or not there *is* something they’re getting at, I’d rather play it safe and make sure we havent missed anything.

What I find interesting about the urls you logged is this: The attacker is spoofing flickr.com in a way that timthumb would have been vulnerable to (prior to version 2.0). That feels awfully coincidental considering the fact that the plugin scans for timthumb…

I wonder if the attack is targeting this file because they’re mistaking it for an actual instance of timthumb?

The randomly generated code is there – it’s in a hidden input with a name of “_wpnonce”. Here’s how the code looks once it’s generated in the admin section:

<input type="hidden" id="_wpnonce" name="_wpnonce" value="2b99b85b2f" /><input type="hidden" name="_wp_http_referer" value="/wp-admin/tools.php?page=cg-timthumb-scanner&tab=options" />

I agree though, I’ll see if I can get anybody higher up to have a look at this thread and make sure everything looks kosher.

After reading further on the second nonce link, it appears that check_admin_referer() is used for putting a nonce on a link (or, I suppose, a form posted using GET), where wp_verify_nonce() is used to check a nonce posted in a form.

It would be nice to get some confirmation on that though.

Alright – after looking through the code (it’s been a while since I wrote this/thought about it), I have some questions – because this still looks secure to me. Well – I should point out: The page should NOT be accessible without authentication, I totally agree.

However, I’m not sure my nonce implementation is wrong, or that anything can be done from accessing that page outside of wp-admin. I don’t use check_admin_referer(), but I do use wp_verify_nonce(), on the code where the actual actions are performed. If the nonce doesnt match, no action is performed (assuming I’m using wp_verify_nonce() right, but I believe I am). This post:

https://markjaquith.wordpress.com/2006/06/02/wordpress-203-nonces/

recommends using check_admin_referer(), as you do. However – this post:

https://www.prelovac.com/vladimir/improving-security-in-wordpress-plugins-using-nonces

suggests wp_verify_nonce – based on the style of my code, I’m guessing I pulled it straight from that post.

Further – the processing code is not in that file (cg-tvs-admin-panel-display.php). That file really just holds display code – the file that does do the processing is class-cg-tvs-plugin.php at line 253. At line 255, before any processing happens, we check if the user has permission to manage options. After that, on lines 272, 283, and 295, you can see where those nonces get checked, based on what the user is trying to do.

Again – I don’t mean to imply there’s no problem here – there is, and I want to fix it – but I want to make sure I know what was wrong and why it was wrong, so I can make sure it gets fixed properly.

A couple of other things:

• I’ll throw in a blank index.php file to prevent directory listing. I should have done this already
• The only reason the page that loads at all is because there’s very little interaction with wordpress – it’s almost all display code (which I mostly try to keep separate from the processing code). However, this makes me realize: All the files in teh plugin *can* be loaded externally, they just fail because they’re trying to interact with WordPress. Is it best practice to include code on *every* plugin file (well, php file) to prevent direct loading? This situation makes me think it is, but I’d love some further input.

I think that covers it. Again – based on my understanding of nonces, and the fact that processing code is stored in another file, which has a permissions check, I don’t think there’s the potential for malicious intent here – but I want to make sure I’ve got my ducks in a row before I release an update. Regardless, I’ll put out an update with the aforementioned changes tomorrow morning – I’d just rather make sure it’s right than have to make 2 releases.

Thanks!

Thanks for the heads up, AITPro! The plugin has been taken down for now, but that means the vuln still exists on people’s sites – I’ll have an update pushed live tomorrow morning, at the very latest.

Hey Superten –

Sorry about that! I havent really done any testing with multisite. I’d be happy to help you fix this and get you back into your admin section – just send me an email at [email protected] if you’re interested.

Thanks!

Mark, what’s likely happened is: The scanner plugin tried to fix itself (it flagged itself as a vulnerable timthumb plugin, because of the code in teh plugin to find the plugin). This broke the plugin, which broke your site.

Unfortunately, I havent been able to nail down why this is happening. If you’re comfortable with it, I’d love to help you sort out hte problem, as well as figure out exactly why it’s happening – if you’re interested, get in touch with me at [email protected].

Thanks!

Man, that is really weird – I’m at a loss as to what could be going on.

Dreamhost is popular enough that I think I’d be getting more reports of this if it was happening to everyone hosted with them.

If you’d like me to help you debug it further, I’d be happy to, but I’d probably need more access – get in touch at [email protected] if you’re interested.

Thanks!

Where are you seeing the 404 – on activation?

Can you tell me who you’re hosted with? This sounds like it could be a security precaution on their end.