FBI 建議用擋廣告軟體降低瀏覽時的風險

在「Even the FBI says you should use an ad blocker」這邊看到的新聞,FBI 的公告則是在「Cyber Criminals Impersonating Brands Using Search Engine Advertisement Services to Defraud Users」這邊可以看到。

起因是有很多網路犯罪行為會透過購買廣告,在搜尋引擎上曝光誘導使用者點擊:

Cyber criminals purchase advertisements that appear within internet search results using a domain that is similar to an actual business or service. When a user searches for that business or service, these advertisements appear at the very top of search results with minimum distinction between an advertisement and an actual search result. These advertisements link to a webpage that looks identical to the impersonated business’s official webpage.

其中一種方式是,使用者輸入關鍵字想要下載某些特定的軟體,這時候網路犯罪者就會透過下廣告的方式,誘導使用者到假的網站下載有後門木馬的軟體:

In instances where a user is searching for a program to download, the fraudulent webpage has a link to download software that is actually malware. The download page looks legitimate and the download itself is named after the program the user intended to download.

這個方式讓我想到之前北韓政府對 PuTTY 的攻擊:「Trojanized versions of PuTTY utility being used to spread backdoor」。

而 FBI 建議個人的保護方式包括了 ad blocking extension,這算是減少被攻擊的管道:

Use an ad blocking extension when performing internet searches. Most internet browsers allow a user to add extensions, including extensions that block advertisements. These ad blockers can be turned on and off within a browser to permit advertisements on certain websites while blocking advertisements on others.

然後建議擋廣告軟體就是用 uBlock Origin,無論是 Chromium 系列的瀏覽器 (包括 Google Chrome),或是 Firefox 都有支援。

裝 uBlock Origin 擋詐騙廣告:金石堂

昨天在噗浪上看到這則:「金石堂的google搜尋推薦第一位是詐騙網站」。

這邊一直在推廣 uBlock Origin,在主要的幾個瀏覽器上都有支援:

從上面那則噗裡的討論可以看到,把一個檢舉掉了,過幾個小時候另外一個還是會冒出來...

網頁的死亡線

是一篇 2017 年的文章,前幾天在 Hacker News 上重新被提出來:「The Line of Death (2017) (textslashplain.com)」。

文章開頭在講瀏覽器 UI 的信任區,這條線以上是 native UI,以下是網站可以任意操控的內容:

所以 UI 上面有些小細節讓你區分,但這其實對不是專精 phishing 的人很不友善:

另外當然就會提到 browser-in-a-browser (以及 picture-in-picture) 類的 phishing 了:

另外提到了 Fullscreen API,這使得信任區間變成 0:

提到 Fullscreen API 所以就去翻資料,意外發現 IE11 居然支援這組 API,雖然是帶 ms 的 prefix,而且不支援一些輔助性的功能 (像是傳回 Promise object)。

這些 UI 與 security 類的問題,主要還是得考慮到使用者未必那麼熟悉,以及就算有經驗的人也很有可能不小心中獎...

iOS App 的釣魚

在「iOS Privacy: steal.password - Easily get the user's Apple ID password, just by asking」這邊作者示範了怎麼釣魚:直接模擬 iOS 的系統視窗跟使用者要密碼。

看了只有「操」... 目前想的到的 workaround 只有在看到類似的視窗時跳回主畫面,透過 Settings 裡確認?

利用 Unicode Domain 釣魚,以及 Chrome 與 Firefox 的解法

一個多禮拜前引起蠻多討論的一篇文章,利用 Unicode Domain 釣魚的方法:「Phishing with Unicode Domains」。

由於這是幾乎完美的攻擊,所以被提出來後 (Security: Whole-script confusable domain label spoofing) 有不少討論:

This bug was reported to Chrome and Firefox on January 20, 2017 and was fixed in the Chrome trunk on March 24. The fix is included in Chrome 58 which is currently rolling out to users.

comment 8 提到:

We do have a whitelist. Essentially you're suggesting that we remove Cyrillic and Greek characters from the list. I'm not sure we want to go down that path.

在新版的 Chrome 58 已經「修正」了這個問題:

Firefox 的討論在「IDN Phishing using whole-script confusables on Windows and Linux」這邊,一開始就直接把票給關了 XDDD:

Indeed. Our IDN threat model specifically excludes whole-script homographs, because they can't be detected programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.

We can't go blacklisting standard Cyrillic letters.

If you think there is a problem here, complain to the .com registry who let you register https://www.xn--80ak6aa92e.com/ .

Gerv

Status: NEW → RESOLVED
Last Resolved: 3 months ago
Flags: needinfo?(gerv)
Resolution: --- → WONTFIX

然後一個月前被提出來看看 Chrome 怎麼做:

Gerv/Valentin, is this something we can/should align with Chromium on?

目前唯一的解法是改 flag,把所有的 Unicode Domain 直接當作一般的 domain 來處理,列出像是 www.xn--80ak6aa92e.com 的網址。

瀏覽器 UI 的死亡線

作者 Eric Lawrence 現在在 Google Chrome team 裡,寫了一篇文章講到瀏覽器上 UI 設計與安全性的問題:「The Line of Death」。

從一開始會假設紅線以上是可信任的:

後來有些操作跨過這條線 (左邊),於是就開始有很 tricky 的方法 (右邊):

甚至反過來利用 icon 讓使用者誤會是表示有訊息要通知使用者:

另外是直接惡搞,假裝是另外一個視窗:

最新的方法是利用 HTML5 的 Fullscreen API 直接搞定所有事情:

花樣愈來愈多了...

利用隱藏的 form input 加上自動完成功能取得敏感資料

anttiviljami/browser-autofill-phishing 這邊示範了怎麼用隱藏的 form input 與自動完成功能取得敏感資料。在這邊可以看到示範 (把 POST 丟到 httpbin 上看 response)。

想法不算困難,但好像也不是很好防... 關掉 autofill 是比較簡單的解法 (我是裝好瀏覽器就會關掉,不過好像很多人都喜歡用這個功能),所以這個問題就丟回給這些 browser vendor 想了 :o

社交工程演練網站 CuttlePhish

Hacker News Daily 上看到的服務:「CuttlePhish」。

CuttlePhish 是個社交工程演練網站,提供演練測試 (Phishing as a Service),付費的方式也很有趣:

Twenty bucks, for up to 100 users. We charge per-batch of emails, (not per-email or per-click). You only pay if somebody clicks one of the links in our emails.

只有在有人點的時候收 USD$20... XD

擋 Open Redirect 的問題...

Open Redirect 的問題可以參考:

這兩個連結。主要是要避免 phishing 的問題上。

一開始是以「只允許 / 開頭」為條件過濾,但 protocol-relative 的 //www.example.com 可以繞開。

如果變成「只允許 / 開頭,但不允許 // 開頭」,是不是就沒事了呢?

在「Evolution of Open Redirect Vulnerability.」這邊又看到新招:「/\www.example.com」。

想要用 parse_url() 檢查?沒問題:

$ php -a
Interactive mode enabled

php > var_dump(parse_url("/\\www.example.com"));
array(1) {
  'path' =>
  string(17) "/\www.example.com"
}

但實際測試會發現 IE8 與 Google Chrome 都會跳到 www.example.com (沃槽),其他瀏覽器就先不測了 ~_~

不過原文說的 ///www.example.comPHP 上測試應該是不會過的?

$ php -a
Interactive mode enabled

php > var_dump(parse_url("///www.example.com"));
bool(false)

反正又冒出一堆問題要處理了 ~_~