Another Guy

I see this one every day, hundreds if not thousands of times.

First off, it’s a distributed attacker. Generally, they all track back to various “instant” could service style hosting companies that allow you to open an account with nothing more than an email and a working credit card. My guess is the guy buys (cheaply) a pack of stolen credit cards, and has a bot that goes out and sets up the servers to scan for vulnerable wordpress installs.

What are they looking for? The request string I see is:

‘450699=1&php4=1&root=1&upl=1&wphp4=1&abdullkarem=1&wp=1&module=1&php=1&php5=1&wphp5=1’

What they are actually trying to access is WSO.PHP or SHWSO.PHP – which are a webshell commonly used by hackers. What this guy (or guys) are trying to do is locate wordpress installs that have already been compromised. Possibly they are blindly tossing a file at the server using a known exploit / upload problem, and then coming back to see if it worked or not.

Recommended is that you can your wordpress directories for wso.php and shwso.php – delete if you find them, and assume you have a security issue and work to change passwords and update any stale code.

Yes, I have tried it, and the current version seems to be more compatible. It’s a good lesson for other developers, you should always try to make sure your code does not depend on deprecated functions in PHP.

Jon, if you are using clouflare or similar services, you cannot use htaccess to block people (or permit access) because the IP address shown is a shared cloudflare address, not the end user address. You can obtain the address in PHP, example, but not at the htaccess level.

You could also do a fairly advanced filtering in PHP that isn’t as easy to set up in htaccess, such as browser type, language, and so on. Yes, it can be done in htaccess, but I can tell you it’s 1000 times easier to get it right in PHP than it is to write a proper regex for htaccess.

You realize the work you’re asking us to do, then mocking, will take at least a month if not more of solid dedicated time, right?

You also realize that we’re all volunteers, right?

I understand in the grand scheme of something that has been available and maintained for 10 years, 1 month isn’t a lot of time.

I don’t really have any answers for you, I just want to make sure you’re aware of those points, because going back through your previous threads, you seem to be unaware that WordPress is free software backed by a non-profit organization and developed/supported entirely by volunteers.

I also understand that with more and more people using wordpress and more and more corporate (and political) customers using wordpress, it won’t be long before something will blow up and all the efforts put in to date will be lost as people tend to run away fast from security issues.

It’s also nice to play the non-profit card, but Automattic sure ain’t suffering. Just sayin’…

If I wanted to volunteer and wanted to work on the product, I would have done so years ago. I already spend 18 hours a day working as it is, I don’t have any room to take anything else on. I am not going to volunteer and then spend my time complaining that I don’t have time to deal with the issues.

Which specific theme or plugin or WordPress vulnerability did you run into that would have been mitigated by a code review or deprecation notice?

Well, two I see often getting tested is Symposium and WP All Import. Yes, both of them have since been fixed, but both of them also had problems related to non-secure file upload / file creation. Both seemed not to do proper file name and type sanitizing, something that would have likely been handled if they had used core functions rather than their own.

Flawed versions in use in the wild must be significant enough that the scripters are actively looking for them TODAY.

The WordPress dashboard on your installation will not produce hits for plugins that are more than 2 years old.

I don’t use it. I come to worpress.org and search for plugins. I get all sorts of stuff, new and old turning up. Stupid me for using the site, right?

More bites. ?? How did you empirically arrive at that number? I’m guessing it’s just a thumb-in-the-air-seems-alright-to-me statement. But why 10%? Why not 75% or 5%?

Let’s look and see. I use a very simple search: Tweet. 9 pages. 33% (3 pages) are a year or less on updates. 1.5 pages are actually updated to current version. 16% are up to date, and 66% of them are out of date or even WOEFULLY out of date. Since wordpress itself doesn’t offer any support back very far, why would you even think it’s useful to have these plugins available?

This really is not a topic where your not knowing what/why those logs are there equates with insecure.

A simple search on Google for almost every one of the things getting hit leads to an exploit page. Most of them are fixed. Most of them have very simple exploits that could have been avoided by enforcing use of core functions for file transactions and requiring proper access / use security via the core. Failure to apply such standards means that the next security exploit plug in or theme is “just around the bend”.

I’m still not clear about the risk you refer to but as I’ve pointed out: the WordPress dashboard on your installation will not produce hits for plugins that are more than 2 years old.

I still point out that a simple search on www.ads-software.com presents a near endless list of out of date plugins. That doesn’t even being to cover plugins from third parties not listed on wordpress but that can be used because there is no simple versioning protection within wordpress.

You’re attempting to make a case for others to do a great deal of work without offering to get involved.

I am getting involved, by showing up and mentioning the the emperor has no clothes, or at best a flesh colored bodysuit that isn’t very flattering.

The “great deal of work” isn’t very hard actually – you guys have all the stats for number of installs, activity, and the like. Start by eliminating what is old, not updated, seldom downloaded… send a notice to the creator that you intend to deprecate it as untended and of unknown security standards. If you find a plug in that is popular but untended, try to find the creator to get back to it, try to get someone to take over the code, or if it’s really useful, give it a code review and bring it up to date.

The real numbers based on incidents from old plugins or themes do not support that effort.

Based on the amount of script kiddies looking to hit that stuff, I would say the problem is much larger than you are seeing. Seeing how many attacks on wordpress sites come from other compromised wordpress sites (it happens often enough for me to notice it)… that means there is enough out there and the message isn’t getting out.

There is no simple answer. However, sticking your head in the sand and saying “from your install, you can’t see those things” isn’t going to make it better.

Ipstenu, security issues happen to everyone. This one happened to point out something very significant, which is needless repetition of code such as genericons. If it’s something being used often, shouldn’t it be a stand alone plug in or “common file” that can be used by many, and could easily be updated or patched based on security issues? Depending on each plug in creator to update their code is to expect failure. Not everyone is active, not everyone is willing.

But what is the likelihood of that happening in volume? I am not asking if it could happen, I am asking out of those 35,000+ plugins what is the expected number of that occurring? It’s a graph-able chart but I’ve not bothered to do the math.

With a large number of wordpress installs that I take care of, I can tell you that I run into errors and problems all the time. Themes updated that no longer work at all (did anyone test it?), recently a theme that entirely dropped the title tags from display. Plugins that cause security issues, themes with tons of java code that is almost always somewhat buggy. They may not be security errors, but they are certainly annoying. The sliders and various gallery uploader tools that have security errors is a pretty long list at times.

Moreover, anyone who logs larger sites will know how many security issues there are. The average script kiddie banging my wordpress installs right now are looking for about 50-80 different packages that have known exploits. That’s just current ones. Who knows how many older ones they just stopped looking for because they code isn’t that common anymore.

I can also say that among 35,000+ plugins, I would guess that somewhere around 10% of them are actually valid and up to date, and the rest are the great unknown. Risk Management (I use to do insurance claims, know the concept) says that the 10% up to date generally won’t be your risk, but the 30,000+ untouched and unloved plugins will be someone’s downfall. You can easily reduce the risks by locking up and potentially eliminating plugins that are no longer maintained and no longer up to date.

You will point to some that are great and not updated. Well, go in and update them as compatible with the current version, and the problem is solved. It is much easier to handle a few known good plugins rather than to leave hundreds or thousands of potential headaches out there waiting to screw up. It could be something as simple as not being compatible with the current version and screwing up someone’s files, it could be not being compatible with current PHP versions… there is a host of potential issues that can be mitigated by retiring old code and deprecating old plugins that are no longer supported and may cause issues.

I have looked and I cannot find a way. Any point beyond the first few lines into wp-login or /admin/index.php invokes the actual site installation, starts up the database connection, and a whole bunch of other things – and no plug in can really run before that.

Asking for a better way is a request and suggestion that their needs to be a hook (say executing a file called “pre-login.php”) before every access, and any code the end user desires can run inside that file without having to hack wordpress to do it.

Basically, there is no way (save for htaccess, which is not always possible to use) to deal with login attempts BEFORE anyone access code. For site operators who only update from a single location, or only have a limited number of people working on their site, it would be very beneficial to be able to have a simple way to limit access by country / IP / whatever other items without first having to completely start up a wordpress session.

htaccess is not always available or not always the best tool for the job here. Services such as cloudflare and other caching services make it harder to use htaccess. Some people may not have access to it.

“You do realize that there’s 35000 plugins, and we didn’t write most of them, correct? We offer plugin hosting here as a service, but we don’t control the content of them in more than a minor way.”

I think that part of the problem is there: There is no simple way for the public to know the difference. When they come to wordpress and download the software and add in some plugs ins an themes off the wordpress site, the thought process is that what is on the site is approved, vetted, or at least held up to a certain standard by wordpress itself.

“I am floored that you think such things are possible by unpaid volunteers. Or, are you volunteering to perform that massive amount of work?”

Perhaps then wordpress should part with a little of the gold and get some actual staff. Millions of installs, tons of plug in and theme downloads per day (often freemium things that don’t do much of anything until you pay)… somewhere in there, there has to be enough of a business model to help protect the ecosystem from swallowing itself.

Perhaps the issue is 35,000 plug ins. Quantity over quality?

Oh, and no, I am not volunteering to come clean up the mess that has been made with this, unless it pays really well. It will likely have to in order to get anyone willing to rake through the muck.

Why was this moved to “troubleshooting”. There is no “trouble” to shoot, this is request and feedback.

“Welcome to the internet. We also have cat pictures.”

Wow. That about sums it up, doesn’t it? We don’t have to worry about security because cat pictures?

I am floored.

“Your ideal is an unattainable one.”

The ideal that wordpress might actually test plug ins, set standards, and adhere to them so that people can’t easily create code that turns malicious? I would think you more than most would understand where most of the security issues come up- plugins and themes, and mostly because they do things to work around the core or do not use proper sanitizing when accepting inputs and processing them outside the core.

Perfection cannot be obtained. Takings steps to try to make the products offered on your service as safe as possible is ALWAYS obtainable… if you want to do it.

Catacaustic, the idea is that plugins (and themes for that matter) should not be able to operate with wordpress files (database, wp-content, and the like) without using the core to do so. $WPDB should be reserved for dealing with OUTSIDE databases and not part of WP itself. At the very most, it should be READ ONLY when it comes to anything related to wordpress.

Most of the risk of code execution is (a) directly accessing the code, and (b) having the code doing something which is not vetted by the core. Many of the problems relate to functions which manipulate images or allow different forms of uploads to occur without proper vetting. It’s a pretty simple thing, every time you add a function that can directly write files onto a server, you add a level of risk of a coding error leading to a problem, or a lack of sanitizing leading to abuse.

I understand that you cannot stop people from doing this. It’s their chocie. However, www.ads-software.com has the choice to allow or not allow plugins and themes to be part of their system (similar to, say, the Apple app store) and can apply standards. Hold the coders to a slightly higher standard, and in turn let the public using these things feel a little more secure in choosing www.ads-software.com rather than other sources for code.

“I don’t know what you’re talking about with regards to Yoast’s plugins. Nor is that really relevant, as Yoast’s plugins are not part of the WordPress core.”

Alas, this is the problem. For end users, WordPress is a “thing”. They may not see the shades of grey different between core and plugins or themes, especially considering that plugins like Akismet (and hello dolly, woo hoo!) are part of the core, and themse such as twenty twelve and such are distributed as part of the core updates. Moreover, some of the most popular plugins (like Jetpack) are “in house” products. So as an example, as you dismiss the Yoast issue, your code code has been cleaning up in themes and plugins. Without reading the code, how would a site operator really know?

My take is generally simple, I assume that none of it gets fixed, and I make sure I fix it myself (a couple of hundred times per update… ). So things like questionable sliders, random upload code, and the like all has to be removed to avoid opening security holes. As there is no way to be certain that a plug in or a theme will delete unused files, the only way to handle them properly at this point is full delete and re-install.

A significant amount of the security issues with WordPress are not in core, but in how plugins work and the code they bring to the table. For the moment, there is no simple way to know if a theme or plug in, even downloaded from WordPress site itself, is safe or tested. The security risks of those products reflect on the whole of wordpress as well.

WordPress has an updater for core – yet updating themes and plug ins is basically copy over and that’s it. No way to know if all the files were fixed, no way to assure that old files were removed, and so on.

Yes, I know… it’s not core. it also doesn’t help make wordpress look very secure.

Oh, and in case I missed it, the installer should be for everything including applying theme updates and plugin updates. They should all go through an installer and be responsible for cleaning up their own messes. The Yoast extra file situation should have been resolved in the next update and the files automatically removed when the installer applied the update.

“Over all the issue is that you’re dealing with code, and code is made to be run. It’s almost impossible in PHP to block a bit of code from running just because you don’t want it to. As soon as you try that people will jsut find ways around it because they want to have their code run as their code, not from some other “black box” system that they can’t control.”

The balance is allowing people to create plugins that can directly access the entire system, and can interact with it without any supervision. That leads to the inevitable issues with programs that let you upload files but do not properly check and sanitize the inputs, leading to those plugins being able to upload executable files or perhaps to have javascript or whatnot added without due consideration.

“It’s almost impossible in PHP to block a bit of code from running just because you don’t want it to”

yet, but it is entirely possible to make it impossible for that code to do anything unless used in context. Almost all of the exploits you see on themes and plugins involve directly accessing a file, which has enough accesses within it’s code to do harm. It’s not a simple concept, but finding ways to make code run only in context would be a major step forward in security.

Possibly that might involve something like session tracking, or verifying that a plug in or theme is currently active before code can have access to the WP variables. Not permitting the databases to be opened, not populating the WP variables… in a lot of cases that would make many plugins and sections of code just fail harmlessly if directly accessed.

“Good themes/plugins already do that with the built-in WordPress functions that are available.”

Hence the problem… perhaps it would be better as part of the process of approving a plugin to be on the www.ads-software.com list that it in fact conforms and uses appropriate built in functions, and doesn’t go rogue and directly write files and such. It would be a real plus for the community if we could feel that everything we can get here is up to snuff and working in the most secure ways possible.

“How would you handle connecting to a remote database to retrieve data that’s outside of the WordPress system?”

Does it matter? The question would be much more about HOW that data is treated as it enters into the wordpress ecosystem and how it is displayed within a wordpress site. If there is something people are going around to avoid the ecosystem, then perhaps it’s something that should be included IN the ecosystem so that it can be properly tested and secured to the higher standards of tested code.

Otto, only “ALL” for the code that you have added in this particular case.

Did update get rid of all the extra stuff in Yoasts plug ins?