Archive for the ‘Blog’ Category

Here we take a glimpse of WordPress fanboys’ mindset. Why WordPress is more than SSH? Because SSH is vulnerable to username guessing (more formal term: enumeration), while WordPress isn’t! But why?

I can repeatedly send password attacks to an SSH server very fast without it being particularly impacted by it.
Hitting a WordPress server very fast would either a) have a very long round trip time or b) bring down the server due to the sudden high amount of database activity.

Look at the old SSH documents, and yeah, a username leak makes it that much easier to run a brute force attack. But this is not SSH. This is a webpage with a login form. The same solutions should not instantly apply just because that’s what people think of as ’secure’.

In no way shall this bug report about leaking WordPress username be forgotten:

There are other ways to verify user names. You can reverse engineer them from the author archive URLs (e.g. http://example.com/author/mark/). I believe the consensus last time this came up was that it was trivial to figure out the user names anyway, and that it is much more user-friendly to tell them when they messed up their username, and not the password. Also, “admin” is created on install, and can’t be changed using WordPress itself, so there’s no hiding that.

In short: default user name is already leaked in multiple ways, it is of no use protecting the user name.

Heh, I suppose this is the reason why WordPress doesn’t need to protect against username enumeration, in addition to all kind of attacks possible. The word ‘insecure’ is blasphemy to WordPress fans and developers alike, and all reports saying WordPress has holes would be automatically countered with ‘Bwahahaha’, be it true or not; while all Automattic hard-coded answer would be ‘please send e-mail to security@wordpress.org’. Of course, sending email to that alias is usually met with dead air. (No, not just me) After my second email report to them about my previous WordPress hole, only the newest employee gave a single line of reply: “we saw that”. Of course, the hole is still there without any fix, even though multiple releases has passed.

Other quotes worth chuckling:

• MD5 is an encryption.
• “WordPress is highly secure by default.”
• Any error must be user or administrators’ problem, not related to WordPress at all.

As promised in previous post (in Chinese, sorry), here is the full advisory of WordPress SQL injection vulnerability I have mentioned. Excerpt below:

It is found that the search function provided within WordPress fails to sanitize input based on different character sets. So if WordPress tries to query MySQL database using certain specific character sets, WordPress search function is exploitable using charset-based SQL injection.

Currently known character sets exploitable include: Big5, GBK, GB18030. All of them may use backslash (’\') as part of multibyte character. WordPress with MySQL database created any other character sets fulfilling such property may also be exploitable.

Executing this attack alone results in exposure of all database content on web interface without need of authentication. However, if combined with other exploits (such as cookie authentication vulnerability disclosed earlier), any remote user can obtain WordPress admin privilege, resulting in server compromise.

Actually, I have long been suspecting this is exploitable, though the real effort to verify such claim doesn’t occur before a few days ago. Given the security track record of WordPress, such thing is entirely within expectation.

Chinese sites which are stubborn enough to continue using Big5 or GBK encoding in database are in jeopardy; but otherwise most sites should be rather safe from this exploit (as most should be using UTF-8). Neither is latin1 character set vulnerable (as used in most earlier default WordPress installation). But in contrary to common belief, it looks like mysql_real_escape_string() doesn’t fix the problem at all. Anybody can confirm or deny this?

2007-12-10 20:55 update: GB18030 is not vulnerable. MySQL 5.0.x doesn’t support this character set at all, don’t know about 5.1 series.

我大概會在短時間內將這個貼上 full-disclosure 和 bugtraq：

想知道圖中那個 e10adc3949ba59abbe56e057f20f883e 作表甚麼嗎？拿這個數字去 www.xmd5.net 查一查，就知道我架設這個測試用的 WordPress 時使用甚麼密碼了。

單從這個漏洞本身來看，最多只能將整個資料庫的內容顯示出來；但如果配合別的漏洞一起，就天下無敵了。例如最近發表的一個 WordPress cookie 漏洞 (適用於 1.5 - 2.3.1)，能夠隨意成為 WordPress 的 admin，但先決條件是能夠讀取 admin 的名稱和密碼，從而合成 admin login 所需的 cookie。我找出來那個漏洞剛好可以不用直接存取資料庫而取出 admin 的名稱密碼，正是那個 cookie 漏洞必須和充分的條件。

不過大家應該不用太擔心，我找出來的漏洞的先決條件很苛刻，大部份的人應該都不會中招；但如果有哪位是使用 Big5, GBK, GB2312 等作為資料庫的 charset，那麼是時候考慮 migrate 至 UTF-8 了。

順帶一提，如果哪個打算建議我先知會 Automattic 的人，那麼可以省下這口氣了。有不少的安全漏洞的 advisory 他們都不于理會，直至有公開的 exploit 方會處理，我對此已到達厭惡的程度。

Whether WordPress default theme can be translated, this issue keeps popping up once in a while. While many translators want to make it usable for most people in the world, Matt Mullenweg resisted this idea with plain blank refusal. Well, at least there is a final answer now.

First the (old) news: the default theme won’t be i18n-ed. The reason in short: for the sake of simplicity.

I beg you, let’s not make a flame war on that, I am almost sure this policy won’t change, so we’d better focus on making our life easier, instead of losing precious time for pointless discussions. Thank you!

Probably due to Matt’s ever-increasing power. I have already given up long time ago, seeing that it just wastes my time. Am I wise? Probably other translators have also realised this dead-end — wp-polyglot list is usually as quiet as a mouse. Anyway, case closed.

I start to feel shameful for using WordPress — or put it precisely, having Matt Mullenweg as the leader. See this WordPress ticket for detail.
Notice that the 2 screen names “rob1n” and “markjaquith” are Automattic employees (the company behind WordPress), and Matt’s own screen name is “matt”.

I can’t describe the “You two just do it as I told; I am thy God, neither you nor the outsiders” attitude very vividly. Better read the whole thing yourself.

---

2007-08-31 edit: Tempted to describe it further. Various users try to file a bug about WordPress linking to a website which has outdated information about browsers, and even Automattic employees agreed. But Matt repeatedly close the bug report as wontfix, and the reason turns out to be — the linked site is Matt’s own creation, even the Adsense ID used is his own ID. People are stepping into his personal garden.

Lately this site, blogsecurity.net, caught my attention. Although a new site, it has already done a really good job disclosing and discussing new vulnerabilites in WordPress, be it serious or not.

One of the most important stuff is its WordPress Scanner, which used to be a downloadable script, but now this thing is available on web only. It tries to scan your WordPress blog, and discover its version, plugins used, and whether it is vulnerable to XSS attack. (Thanks to this scanner, I have fixed some of the problems in my own blog.)

And it is not holding back new WordPress holes from disclosure — for example, a new article yesterday showed how to perform enumeration on WordPress installation by brute force, so that valid usernames can be found, as a stepping stone on obtaining username / password. And everybody is using the default ‘admin’ username, right?

The share of XSS vulnerabilities would not be omitted. Just counting post-2.2.1 ones, there are at least 2:

• wp-login.php cross domain redirection

  http://legitimate.com/wordpress/wp-login.php?redirect_to=http://evil.com

• wp-pass.php redirection

  http://vulnerable.blog/wordpress/wp-pass.php?_wp_http_referer=http://evil.com 

Here is a good quote from one of them:

WordPress have apparently said they will resolve this vulnerability in v2.2.2.

And indeed, none of which is fixed in WordPress source code repository at all as of now. (2 weeks after the latter vulnerability is disclosed, that is) And there is no apparent schedule for 2.2.2.

Overall, this site provides a good reading for those who care about their WordPress’ safety.

上個月 Ben Lau 向我提及功夫輸入法這個 project；其中一個有趣的地方是，這個 project 是由兩個香港人負責的。撇開負責的人不說，單說 project 本身，是一個在 web 介面使用的中文（也可以是別的語言）輸入法，系統本身不需要安裝任何輸入法，只要有個瀏覽器就可以用了。即是說用英文 Windows 也可以在瀏覽器中入中文字。當我看過 demo 不久，就在想有沒有可能在 WordPress 裏面用 —— 於是寫了點東西出來。

花的時間不多，主要都是用在解讀 GownFull 輸入法如何讀取設定，和考慮如何將設定簡化，並透過 WordPress 的資料庫儲存設定。本來 GownFull 的設定方法頗為原始，要人手修改 config.php，現在不用了，而且可以在 WordPress 的管理介面選擇啟用哪幾種輸入法。暫時只在 blog 留言的位置啟動輸入法，遲些考慮會不會在 post 文章的介面也啟動吧。

其實已經想不到有甚麼功能要加了，日後最麻煩的，恐怕就是要從 GownFull 的 source code 定期更新；只是一個月，就多了 mimeTeX 的輸入法了，看來他們開發的速度不算慢。還有就是想更新一下它的倉頡和速成碼表：好像很多字都 map 到 PUA（即造字區）去，這樣對於 Unicode adoption 很不利。

有興趣想試的話可以在這裏留言，或者私下問我，因為我還未想 Google 找得到自己的 subversion repository。另一方面也在自己的站安裝了（在留言時留意一下左上角）。本應到 WordPress 登記開一個 subversion 戶口的，但 WordPress 已漸漸顯露出商品化的徵兆，不能賺錢的事務已經開始拖得就拖，有些人一個月也沒有回覆。或者我在 Google Code 開個 project 算了。