Archive for the ‘Web’ Category

一則只有寥寥數字的新聞，竟引起我的注意：

李投資逾億美國社交網站

第一次從標題就可以猜中新聞的所有內容，幾乎一字不漏。現在美國哪個社交網站成為天之驕子？全行皆知現在是 Facebook，根本不用說，MySpace 已經過氣了。哪個姓李的人會做這種投資？因為以往工作經驗的關係，立即就估中，不過不是李澤楷哪。(相信看到這句後，有些人會回想起當年的日子。) 這時第一個在腦海中浮現的字，就是「科網股 2.0」。想不到魔手這麼快伸到外國的 Web 2.0 了，且看看 Facebook 何時完蛋。不過，不同於香港那種純粹炒爆谷，Facebook 的大老闆比較懂得生意經，公司也比較有實力，沒像香港般，只有個不能用的 webmail 竟也可以上市，用幾億也搞不成一個網站。

2008-03-31 更新：原來我是井底之蛙。

As most people remotely interested in computer security should know, bugtraq is one of the ultimate mailing list one should subscribe in order to get the latest news or vulnerabilities (sans full-disclosure and a few others). But few people mentions what should be done before sending to the mailing list, and what will happen afterwards. Here is my little experience to be shared:

1. Before sending email, make sure the email is properly signed with PGP or GPG or whatever. There is a mailing list maintainer watching over the list; email will be validated before they can be delivered to the mailing list. During the first time, the maintainer told me personally my email is delivered successfully.
2. For me the most interesting part is the ‘aftermath’. Most likely the following things will be found in your mailbox afterwards:
1. A few or no reply to your email (depends on people’s interest in the content, disputability, etc).
2. Lots of “out of office” reply. So many.
3. Several “This address does not exist” or “mailbox full” error from other mail servers around the world.
4. And what distinguished bugtraq from most mailing lists: one or two email from Russia or East Europe or wherever, asking you to join malicious groups or exchange your ’scripts’ with $$$.

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.

今次破戒了。本來還說永遠不再碰維基這種玩權力鬥爭、機械 admin 和兩岸互相傾軋的地方，結果還是忍不住出手。在隨意瀏覽時，看到某一頁有些「不符合質素」的內容，開始時還以為是編輯者弄出來的，細看一下編輯紀錄，原來是某個網站的管理者投訴維基侵權，但因為投訴無門，於是逕行編輯該頁，加上自己的投訴內容；但這被那些如同機械的編輯者視為破壞而刪除。

這種和機械人一樣的人，不只是金字塔底層的編輯，連最高層的也大不乏人。很早時已經看不順眼，所以玩大一點：即使明知如何進行正式投訴也不去做，而選擇更公開、公平、公正地奚落這種管理手法：紅色的字是我加的，黑色的字則是相關網站的擁有者的投訴原文。如果正式投訴，到頭來還是正式處理，不曉得汲取教訓。

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 算數了。