Posts tagged ‘exploit’

比之前提及來自 Mandriva 那一封電郵更過癮。今次有可能是來自俄羅斯、白俄羅斯之類的國家的。內容也很簡單，只是問我還有沒有任何 0-day exploit (請看英文解釋，中文維基那篇是垃圾來的)，如果有的話，想我開個價錢。詭異至極。可能是因為上次 disclose 了 WordPress 的漏洞的緣故吧。

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 方會處理，我對此已到達厭惡的程度。

昨天從某個 security 的網站看到這個 WordPress exploit，只能讚不絕口，因為它根本是將以往所有 WordPress 版本的 exploit 集大成於一身，由最早的 1.5 版本至最近的 2.2.2，全部都有方法攻破。

日日為 web application 追新版本真是很辛苦，特別是自己有改動的時候，簡直叫苦連天。難怪許多網站都有這麼多漏洞，有些甚至明知道有也不會更新。更新所消耗的時間實在多得過分。我能夠追趕 WordPress 的速度也僅僅是因為寫了 script 來半自動化。如果沒有特殊要求的話，可能已經用 blogspot 算數了。

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.