Audio of my talk at EUSecWest 06 posted

I’ve finally moved over to another hosting provider that offers me the storage and bandwidth I require for my growing sites, and I can finally offer you the recording of my EUSecWest 06 presentation about Network Security Monitoring: Theory and Practice.

Just to note that Mr. Murphy was present at the conference, and the demo was totally fubar’ed. Next time I’ll go with a pre-recorded demo or just screenshots. And sorry about the sound quality, the audio was recorded on the same machine I had my slides / demo on.

End of the Wordpress saga

Matt has updated the Wordpress 2.0.2 release notification and properly given credit to my contribution to make Wordpress a more secure software.

As I understand it there was some lack of communication within the Wordpress team when Matt wrote the release advisory and was never informed about my contribution. I still hope that the Wordpress team does take my suggestion under consideration and implement processes and procedures to make sure this sort of thing does not happens again.

With this I put the Wordpress issue to rest. Thank you all so much for your support and feedback.

Cross Site Scripting vulnerability in Wordpress 2.0.1

This blog post was originally published on the 4th March 2006, but was removed until a patched version of Wordpress was released to give the Wordpress users out there a chance to update their installations.

Wordpress 2.0.1 has an reflected Cross Site Scripting vulnerability in /wp-admin/options-general.php. You need to be logged in to use it. The exploit URL would be something like this:

http://host.domain.tld/wp-admin/options-general.php?page=%3CSCRIPT%3Ealert(%22XSS%22);%3C/SCRIPT%3E

Due to the fact that it’s an reflected version and you have to be logged in to use it I don’t think it’s very suspectable for malicious usage. The fix is pretty simple as seen by the diff below:

$ svn diff wp-admin/admin.php Index: wp-admin/admin.php
===================================================================
— wp-admin/admin.php  (revision 3513)
+++ wp-admin/admin.php  (working copy) @@ -61,7 +61,7 @@
}  if (! file_exists(ABSPATH . “wp-content/plugins/$plugin_page”))
-                       die(sprintf(__(’Cannot load %s.’), $plugin_page));
+                       die(sprintf(__(’Cannot load %s.’), htmlentities($plugin_page)));
if (! isset($_GET[’noheader’])) require_once(ABSPATH . ‘/wp-admin/admin-header.php’);

I have notified the Wordpress security team about this bug, and hopefully we will see a public fix soon.

Take care.

UPDATE: Mark Jaquith and David House on the #wordpress IRC channel worked up an possible exploit scenario, which made me mark this post as private until a public fix for this vulnerability is published. The attack scenario they came up with is the following code. If disguised with something like tinyurl an administrator might be fooled to click on the link and set the password to a pre-defined value (or modify any other settings).

Responsible Disclosure of Security Vulnerabilities

Recently I reported a Cross Site Scripting vulnerability in Wordpress to their security team, and complied with their every demand (and suggestion) - including unpublished my finding report on this website until a patched version is released and people have had a chance to upgrade. The problem is that they never gave me credit for the finding. Yes, that’s right - they never mentioned my contribution to make Wordpress a more secure software, even when they outright promised me credits.

From the #wordpress-dev channel on Freenode IRC network:

Mar 04 19:10:02 [MarkJaquith] We'll make sure you get credit

This is perhaps something I would expect from some vendors of propriety software (and no, Microsoft is not one of them), but not from a prominent open source project as Wordpress is.

As a security consultant, researcher and developer the only thing I (and others like me) have is our reputation. By not giving credit where credit is due, I don’t get any recognition of my contributions which could be taken in the view that my contributions were not important. This is very strange in this case, as they even used the patch I submitted verbatim.

Responsible disclosure is a two-way street, where the security researcher comply with industry best practices and vendor disclosure policies and in return the vendor gives credit to the researcher for his or hers contributions. It is also important to keep the security researcher in the loop about the progress as well, else the researcher might think that nothing is happening and might pre-maturely release the vulnerability and label the vendor as non-responsive.

If the communication with the Wordpress security team drastically improves, I might consider to start selling those vulnerabilities to the highest bidder - because then I at least get rewarded financially for my research. This would of course be on a vendor by vendor basis, where vendors who honor their part of responsible disclosure do not need to worry.
My suggestions for the Wordpress security team is the following:

1. Have an auto-responder on the security@wordpress.org address which confirms to the reporter that the mail system has recieved it.
   There was no communication at all through email, or othervise, letting me know that you even recieved the email in the first place. Only later I got contacted by Donncha O Caoimh, letting me know that he patched Wordpress.com against the vulnerability. As his email contained my email I can assume with great confidence that the email sent to the Wordpress security team was in fact recieved.
2. Communicate to the reporter when the vulnerability has been confirmed.
   There were some IRC communication on the topic, but an email reply isn’t that time consuming.
3. Communicate to the reporter when the patch has been created, possible ask them to test it out for themselves as well.
   My submission included a patch, which was working and fixed the vulnerability (and later used verbatim in the patched version).
4. Let the reporter know when the patched version will be released.
   I had to constantly ask on IRC what the progress status was.
5. Make sure that the reporter recieves propper credits where credit is due.
   The Wordpress team obviously failed on this.

Wordpress 2.0.2 released – Upgrade now!

There are several security vulnerabilities that has been fixed in Wordpress 2.0.2.

On the 17th of March, 00:00 Singapore time (GMT +0800) I will release the details of the vulnerability I discovered in Wordpress 2.0.1, including what was done to fix it.

For now, upgrade Wordpress and take care.

Linksys WRT54G/GS Hardware Versions Under the Knife

I was looking for information where I could put a JTAG interface on my Linksys WRT54G / WRT54GS routers, and found some pretty good information at LinksysInfo.org. I’ll post step-by-step instructions once I get around to solder the connections on them.

Structured vulnerabilty research of Wordpress

I thought that I should get more structured in my vulnerability research of Wordpress, and I thought that I should start off by sorting out how the code is tied together. After Google’ing and asking around a bit I was directed to a blog entry about KCacheGrind. That made me remember that GraphViz is a pretty neat tool to generate graphs of stuff, the problem is how to generate the code the GraphViz expects. After some more Google’ing I found a tool called codegraph, which seems to fit the critera.
After installing codegraph (and it’s dependencies) I ran it like this:

$ cd /path/to/wordpress/src/
$ codegraph -F “*.php */*.php */*/*.php */*/*/*.php” -S wordpress-2_0_1.svg

Which generated an 1.9 Mb SVG file with the relationship between the different pieces of code. After loading the SVG file into InkScape I quickly located what appeared to be dead (unused) code. But tracking down the relationships using the SVG format isn’t really optimal. It’s great for an overview, but unless you have a 2 meter wide plotter to print it out on it isn’t that much of use (except it looks kinda cool).

What I really need is something that generates me documentation of who depends on a particular function and what that function depends on in return (parent and child dependencies). It would be really cool if it also did document what parameters the said function supports. Unfortunatly codegraph doesn’t support that so I am still hunting for software that allows me to do that. If you know any such software do please let me know by leaving a comment.