又是 ImageMagick 出包...

ImageMagick 的 information leaking,然後 Yahoo! 很無奈的中獎,所以被稱為 Yahoobleed:「Yahoo! retires! bleeding! ImageMagick! to! kill! 0-day! vulnerability!」。發現問題的作者把問題寫在「*bleed continues: 18 byte file, $14k bounty, for leaking private Yahoo! Mail images」這邊。

作者利用 ImageMagick 的不當處理,取得 uninitialized memory 的資訊,藉以取得可能是上次轉檔的記憶體內容。而這個 jpeg 只有 18bytes (所以作者戲稱每個 byte 價值 USD$778):

A robust bounty of $14,000 was issued (for this combined with a similar issue, to be documented separately). $778 per byte -- lol!

目前的 workaround 也很簡單 (官方採用了),呼叫 ResetMagickMemory 避免 leaking (咦,這方法好像哪邊怪怪的):「Reset memory for RLE decoder (patch provided by scarybeasts)」。

Yahoo! 也放出了判斷是否為色情圖片的方案

感覺好像是從 AlphaGo 大勝李世乭開始,透過各類 neural network 的技術就一直冒出來...

Yahoo! 這次放出來判斷是否為色情圖片的也是同源的技術:「Open Sourcing a Deep Learning Solution for Detecting NSFW Images」。

當年沒辦法做的事情,現在的技術已經成熟到被 open source 出來了...

Yahoo! 這次應該是史上最大的一次 leak...

Yahoo! 這次爆出來的 leak 應該是目前史上最大的一次:「An Important Message About Yahoo User Security」。

目前 Yahoo! 的研判是 2014 年時由政府單位搬出去的:

A recent investigation by Yahoo has confirmed that a copy of certain user account information was stolen from the company’s network in late 2014 by what it believes is a state-sponsored actor.

這包括了密碼的部份 (受過不同程度的 hash 保護):

The account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (the vast majority with bcrypt) and, in some cases, encrypted or unencrypted security questions and answers.

照這樣的用詞,猜測是登入時一直將舊的密碼換掉... 類似於 $2a$ 這樣可以知道編碼方式的機制。


Based on the ongoing investigation, Yahoo believes that information associated with at least 500 million user accounts was stolen and the investigation has found no evidence that the state-sponsored actor is currently in Yahoo’s network. Yahoo is working closely with law enforcement on this matter.

依照目前在「Have I been pwned? Check if your email has been compromised in a data breach」上的資料,最大的應該是 MySpace 的 3.5 億筆,看起來這次會刷記錄...

透過搜尋引擎找 Hostname

看到「Fast subdomains enumeration tool for penetration testers」這個專案,可以透過多家搜索引擎找 hostname 出來做滲透測試。

支援五個大的搜尋引擎,以及 NetcraftDNSdumpster

Sublist3r currently supports the following search engines: Google, Yahoo, Bing, Baidu, and Ask. More search engines may be added in the future. Sublist3r also gathers subdomains using Netcraft and DNSdumpster.

不過沒有把 Yandex 放進去...

Google Chrome 上看連線是使用 IPv4 或是 IPv6

想說應該會有 extension 可以看連線是 IPv4 或是 IPv6,找了一下果然有:「IPvFoo」。

右上角會出現目前連線的屬性。透過 Google Chrome 提供的 webRequest 取得資訊後更新上去的。

目前比較常見的站台應該是 Facebook (包括 Instagram)、GoogleYahoo,也剛剛好都是 HTTPS Policy 的先驅... 不過可以看出來不是所有的資源都走 IPv6,還是有不少走 IPv4 的 domain。

Twitter 的主網站沒有 IPv6,但幾個自己的子網域有?看起來還在逐步測試開通...

HiNet 的 IPv6 服務已經可以透過網路櫃台直接線上申請 (需要幾個工作天開通),我用 Ubuntu 可以 PPPoE 取得...

RSA Conference 2015 禁止 Show Girl

前幾天的消息:「RSA Conference Bans "Booth Babes"」。報導出自於「RSA Conference bans ‘booth babes’」。


All Expo staff are expected to dress in business and/or business casual attire. Exhibitors should ensure that the attire of al staff they deploy at their booth (whether the exhibitor’s direct employees or their contractors) be considered appropriate in a professional environment. Attire of an overly revealing or suggestive nature is not permitted. Examples of such attire may include but are not restricted to:

  • Tops displaying excessive cleavage;
  • Tank tops, halter tops, camisole tops or tube tops;
  • Miniskirts or minidresses;
  • Shorts;
  • Lycra (or other Second-Skin) bodysuits;
  • Objectionable or offensive costumes.

These guidelines are applicable to all booth staff, regardless of gender, and will be strictly enforced. We reserve the right to request that individual booth staff change their attire or leave the premises immediately if we feel their appearance might be offensive to other exhibitors or attendees.

讓我想起 2009 年 Yahoo! 辦的 Taiwan Open Hack Day:「Yahoo Sorry About Lap Dancers at Hack Day in Taiwan–So What's the Excuse for Last Year's Go-Go Girls?」。

Flash 的 crossdomain.xml 架構問題

在「"Lax" Crossdomain Policy Puts Yahoo Mail At Risk」這篇裡面看到不安全的 Flash 造成的問題:「Seizing Control of Yahoo! Mail Cross-Origin... Again」。

找有問題的 swf 檔案 (hosting 在 crossdomain.xml 允許的網段下),然後利用 injection 或是根本就沒檢查權限來打趴... 把 swf 當跳板用就是了 :p

文章後面那個 Disclosure Timeline 看起來頗心酸 :o

用 Require-Recipient-Valid-Since (RRVS) 解決帳號失效的問題

在「Facebook Yahoo Require-Recipient-Valid-Since SMTP Extension」這篇看到 Require-Recipient-Valid-Since (RRVS) 變成 Proposed Standard 了:「The Require-Recipient-Valid-Since Header Field and SMTP Service Extension」(RFC 7293)。

起因是從 2013 年的「yourname@yahoo.com Can Be Yours!」這篇開始的:Yahoo! 宣佈會釋出太久沒有使用的 @yahoo.com 帳號讓其他人可以註冊。

而這導致了帳號綁定問題:如果使用者先前在 Facebook 上 (或是其他服務) 有綁定 Yahoo! 帳號,而他的 Yahoo! 帳號被釋出被其他人拿走後,其他人就可以利用重設密碼的功能取得 Facebook 帳號權限。

Yahoo! 對這個問題的解法是透過 Require-Recipient-Valid-Since 處理,服務方 (像是 Facebook) 在發出重要信件時帶入 Require-Recipient-Valid-Since,要求這封信必須在某個時間點後有效,才能讓收信者看到這封信的內容。

Facebook 的人在「Protecting Facebook Accounts With New Email Standard」也提到了這個新標準。