It’s been around 48 hours since WordPress 3.4 beta 1 was officially released, with around 20 new tickets opened, and at least as much closed since then, there are currently 171 tickets open.
Let’s see what changed this week in 3.4 and future releases of WordPress.
Produce a raw dump of some of the core parts that should help shed some light on issues regarding WordPress rewrite rules, permalinks and missing template files when a 404 is encountered. Fork, improve, comment. This is for environments with no fancy IDEs, Xdebug, debug plugins.
It is no secret that the WordPress Core interacts with remote APIs maintained by WordPress DOT org team. The most direct manifestation of these calls are plugin, theme and Core update notifications, and XML feeds in the Dashboard. Let’s take a look at all (hopefully) of the calls that WordPress is able to make, analyze the protocols and the data being exchanged.
Another great week of WordPress 3.4 development and polishing, with everyone hoping to see beta this week, it has been postponed to later this weekend or sometime next week. 163 tickets (at the time of writing) are assigned to the WordPress 3.4 milestone.
A new phishing scam is doing the rounds and it’s targeting WordPress plugin developers. This is a very interesting attack vector, explosively damaging when successful.
Dear WordPress Plugin Developer,
Unfortunately, a plugin you are hosting has been temporarily removed from the WordPress repository. We are going to manually review your plugin because it has been reported for violating our Terms of Service. If your plugin does not get approved then it will be permanently removed from the WordPress repository.
You can check if your plugin has been approved or rejected at
https://wordpress.org/extend/plugins/my-plugin-status/
Very unconventional, not your usual e-mail or PayPal account phishing, it’s WordPress. A little short of 20000 plugins, shared among less authors, so not a lot of victims to play with. The subsequent aim of a phishing attack appears to be the modification of plugins to inject malicious code and get WordPress installations with the plugin infected. People using the plugin would then update and bring the bad code in.
Looks quite difficult to accomplish though; it’s hard enough to get a plugin developer to not notice a fake WordPress.org site, then not smell anything funny going on even if they enter their credentials. Hmmm…
The phishing site is currently disabled (404), looks like the attack has been dismantled quite quickly and efficiently. The link https://wordpress.org/extend/plugins/my-plugin-status/ now leads to a nice plugin by the WordPress team. Well done, WordPress.org for acting quickly and efficiently.
To users of plugins, be aware of sudden updates, review code, contact the authors.
Source: Warning Phishing Attempt @ WordPress.org
Sometime this weekend or next week (or maybe next week) WordPress development will feature freeze, meaning no more features will be added. And will be left with more or less some of the features that are expected in WordPress 3.4.
Ready. Steady. Go!
About a week ago I did a post on Tiny Projects Inspired by WordPress. Readers who actually visited the Code.WordPress Trac would have noticed a tool called servermattic, which is described modestly as “install files and applications to many servers according to their role“.
servermattic is a template configuration that allows for deployment of code and configurations across multiple servers – write once, deploy on many machines, update as much as you want with revisions.
Today’s been the craziest day I’ve had for quite a long long time. It’s 5AM and I still haven’t done my WordPress trunk roundup for this week. So hot cup of fresh tea ready (by the way, from today on you can hook me up with some tea to keep me going day and night :D), off we go!
Yesterday I wrote a post titled On WordPress Pingbacks. While writing this I came to several conclusions that resulted in some interesting experiments and results.
I was going to publish my results along with that post, however, I wanted to make sure that the WordPress Security mailinglist had nothing against my publishing such information. With no word from them (I guess I expected too much to be contacted back within 24 hours), I’ve decided to dedicate a whole article to the Pingback attack, its potential, its limitations and further considerations and concerns.
WordPress supports Pingbacks and these are enabled by default. Having noticed a missing pingback from one of my posts and having made sure that it wasn’t caught as spam or still pending, I decided to investigate a bit and try to resend it manually.
Armed with the Pingback specification, and the XML-RPC RFC, I was able to successfully have a request cURLed over.
curl "https://.../xmlrpc.php" --header "Content-Type: text/xml" --data "<?xmlversion="1.0"?><methodCall><methodName>pingback.ping</methodName><params><param><value><string>https://.../</string></value></param><param><value><string>https://.../</string></value></param></params></methodCall>"
<?xml version="1.0"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>https://.source./</string></value>
</param>
<param>
<value><string>https://.target./</string></value>
</param>
</params>
</methodCall>
For which I got a nice response:
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value>
<string>Pingback from https://.source./ to https://.target./ registered. Keep the web talking! :-)</string>
</value>
</param>
</params>
</methodResponse>
Mission accomplished, got the Pingback thorough, great! But what if…?