Zoom 預設開啟密碼原因

最早的時候用 Zoom 只需要知道 meeting room 的編號就可以連進去,產生連結時也只需要提供號碼就能進去,後來 (不知道什麼時候開始的) 產生出來的連結會包括一組 token,而預設加入房間也需要密碼了。

現在知道原因了,因為被安全通報了:「Zoom Fixes Flaw Opening Meetings to Hackers」。

除了上面講到的問題以外,另外一個漏洞是本來的連結網頁就有資訊可以辨別是否為合法的 meeting room,可以讓攻擊者很快速的判斷哪些 meeting room 可以連進去。這次的修改變成不檢查,直接帶到 Zoom 的應用程式裡面,增加一些難度,但攻擊者還是可以透過 API 掃出來。

這主要是當初設計上的安全問題,當初沒有設計那麼長,應該就是考慮太長的號碼會讓使用者不太容易手動輸入...

讓手機上瀏覽器自動帶出數字鍵盤的方式

在「HTML attributes to improve your users' two factor authentication experience」這邊看到關於讓使用者輸入 2FA (通常是數字) 比較流暢的設定。

原始是上面這張這樣,目標是希望下面這張這樣,當透過 SMS 2FA 時可以提供選項直接貼上,而且也自動帶出數字鍵盤:

給出的幾個重點在於 inputmodepattern 以及 autocomplete

<input
  type="text"
  name="token"
  id="token"
  inputmode="numeric"
  pattern="[0-9]*"
  autocomplete="one-time-code"
/>

查了一下 caniuse.com 上面的支援度,pattern 基本上都支援了,autocomplete 在這邊用到的 one-time-code 基本上也沒問題,只有 inputmode 這邊支援度比較差,IE11 (基本上不會更新了)、FirefoxSafari 沒支援。

用 QR Code 讓使用者可以直接登入 WiFi

在「Encoding your WiFi access point password into a QR code」這邊看到的,不過之前在公司頻道裡面也有看到類似的東西...

產生這樣的 QR code 讓使用者掃就可以了:

WIFI:T:WPA;S:<SSID>;P:<PASSWORD>;;

放在家裡也不錯就是了,讓客人來可以直接掃,尤其是密碼超級長的時候...

Ken Thompson 的密碼

剛剛看到這串還蠻歡樂的...

起因於 BSD 3 的程式碼裡面有個 /etc/passwd,而且是帶有 crypt 的版本:「unix-history-repo/etc/passwd」。

裡面有蠻多密碼都已經被解出來了,但還是有些還沒解出來... 而最近的消息是 ken (Ken Thompson) 的密碼被解了出來:「Ken Thompson's Unix password」。

From: Nigel Williams <nw@retrocomputingtasmania.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Recovered /etc/passwd files
Date: Wed, 9 Oct 2019 16:49:48 +1100

ken is done:

ZghOT0eRm4U9s:p/q2-q4!

took 4+ days on an AMD Radeon Vega64 running hashcat at about 930MH/s
during that time (those familiar know the hash-rate fluctuates and
slows down towards the end).

另外解出來的人也發現了這組密碼是一組西洋棋的 Descriptive notation,跟 Ken Thompson 的背景也相符:

From: Nigel Williams <nw@retrocomputingtasmania.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Recovered /etc/passwd files
Date: Wed, 9 Oct 2019 16:52:00 +1100

On Wed, Oct 9, 2019 at 4:49 PM Nigel Williams
<nw@retrocomputingtasmania.com> wrote:
> ZghOT0eRm4U9s:p/q2-q4!

BTW, is that a chess move?

不過我覺得最好玩的是這個,不確定是不是本尊就是了:

From: Ken Thompson via TUHS <tuhs@minnie.tuhs.org>
To: Andy Kosela <akosela@andykosela.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Recovered /etc/passwd files
Date: Wed, 9 Oct 2019 01:53:25 -0700

congrats.

On Wed, Oct 9, 2019 at 1:16 AM Andy Kosela <akosela@andykosela.com> wrote:
>
> On 10/9/19, Warner Losh <imp@bsdimp.com> wrote:
> > On Tue, Oct 8, 2019, 11:52 PM Nigel Williams
> > <nw@retrocomputingtasmania.com>
> > wrote:
> >
> >> On Wed, Oct 9, 2019 at 4:49 PM Nigel Williams
> >> <nw@retrocomputingtasmania.com> wrote:
> >> > ZghOT0eRm4U9s:p/q2-q4!
> >>
> >> BTW, is that a chess move?
> >>
> >
> > Most common opening.
> >
>
> Descriptive chess notation is not as popular today as it was back in
> the 70s, but it actually makes perfect sense as Ken is a long time
> chess enthusiast.
>
> --Andy

還有 Rob Pike 對這件事情不怎麼贊同的看法:

From: Rob Pike <robpike@gmail.com>
To: Nigel Williams <nw@retrocomputingtasmania.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Recovered /etc/passwd files
Date: Wed, 9 Oct 2019 09:59:43 -1000

I coulda told you that. One tends to learn passwords (inadvertently) when
they're short and typed nearby often enough. (Sorry, ken.)

If I remember right, the first half of this password was on a t-shirt
commemorating Belle's first half-move, although its notation may have been
different.

Interesting though it is, though, I find this hacking distasteful. It was
distasteful back when, and it still is. The attitudes around hackery have
changed; the position nowadays seems to be that the bad guys are doing it
so the good guys should be rewarded for doing it first. That's disingenuous
at best, and dangerous at worst.

-rob


On Tue, Oct 8, 2019 at 7:50 PM Nigel Williams <nw@retrocomputingtasmania.com>
wrote:

> ken is done:
>
> ZghOT0eRm4U9s:p/q2-q4!
>
> took 4+ days on an AMD Radeon Vega64 running hashcat at about 930MH/s
> during that time (those familiar know the hash-rate fluctuates and
> slows down towards the end).
>

意外的引誘到一群人跑出來...

改 Open Distro for Elasticsearch 預設密碼的方式

AWS 弄出來的 Open Distro for Elasticsearch 因為內建了安全性的功能 (參考「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」),應該是目前新架設 Elasticsearch 的首選。

不過裝好後預設有五個帳號,但從 Open Distro 的 Kibana 介面無法修改改其中兩個使用者的密碼 (adminkibanaserver),要修改密碼發現得花不少功夫,不知道為什麼要這樣設計 :/

這邊講的是透過 RPM (以及 deb) 的方式的修改方式,如果是 Docker 的方式請參考後面提到在 AWS blog 上的文章:「Change your Admin Passwords in Open Distro for Elasticsearch」。

首先先透過 hash.sh 產生 bcrypt 的 hash,像是這樣 (輸入 password 當密碼):

bash /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh
WARNING: JAVA_HOME not set, will use /usr/bin/java
[Password:]
$2y$12$QchkpgY8y/.0TL7wruWq4egBDrlpIaURiBYKoZD50G/twdylgwuhG

然後修改 /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml 檔案裡面的值,順便改掉 readonly 的部分。

接下來是把這個 internal_users.yml 檔案的設定更新到 Elasticsearch 裡。由於這邊需要讀 /etc/elasticsearch/ 的東西,所以偷懶用 root 跑:

sudo bash /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/root-ca.pem -cert /etc/elasticsearch/kirk.pem -key /etc/elasticsearch/kirk-key.pem

做完後可能要重跑 Elasticsearch 與 Kibana:

sudo service elasticsearch restart
sudo service kibana restart

或是重開機... 順便測試看看重開後有沒有生效。理論上修改完成後,就是用新的帳號密碼連到 Kibana。

上面的方法是參考了「Default Password Reset」(先找到這篇) 與「change admin password」(後來在 AWS blog 的文章上發現的 GitHub issue 連結) 這邊的資訊。

官方的說明文件則是在寫這篇文章時才找到的,平常搜尋時不太會出現:「Apply configuration changes」。

Facebook 員工爆料內部密碼存了明碼

Krebs on Security 這邊看到的:「Facebook Stored Hundreds of Millions of User Passwords in Plain Text for Years」,Facebook 官方的回應在「Keeping Passwords Secure」這邊。

幾個重點,第一個是範圍,目前已經有看到 2012 的資料都有在內:

The Facebook source said the investigation so far indicates between 200 million and 600 million Facebook users may have had their account passwords stored in plain text and searchable by more than 20,000 Facebook employees. The source said Facebook is still trying to determine how many passwords were exposed and for how long, but so far the inquiry has uncovered archives with plain text user passwords dating back to 2012.

另外的重點是這些資料已經被內部拿來大量搜尋 (喔喔):

My Facebook insider said access logs showed some 2,000 engineers or developers made approximately nine million internal queries for data elements that contained plain text user passwords.

另外是 Legal 與 PR 都已經啟動處理了,對外新聞稿會美化數字,降低傷害:

“The longer we go into this analysis the more comfortable the legal people [at Facebook] are going with the lower bounds” of affected users, the source said. “Right now they’re working on an effort to reduce that number even more by only counting things we have currently in our data warehouse.”

另外也會淡化後續的程序:

Renfro said the company planned to alert affected Facebook users, but that no password resets would be required.

去年的另外一則新聞可以交叉看:「Facebook’s security chief is leaving, and no one’s going to replace him」:

Instead of building out a dedicated security team, Facebook has dissolved it and is instead embedding security engineers within its other divisions. “We are not naming a new CSO, since earlier this year we embedded our security engineers, analysts, investigators, and other specialists in our product and engineering teams to better address the emerging security threats we face,” a Facebook spokesman said in an email. Facebook will “continue to evaluate what kind of structure works best” to protect users’ security, he said.

看起來又要再換一次密碼了... (還好已經習慣用 Password Manager,所以每個站都有不同密碼?)

喔對,另外補充一個概念,當他們說「我們沒有證據有人存取了...」的時候,比較正確的表達應該是「我們沒有稽核這塊... 所以沒有證據」。

最近很紅的密碼...

前幾天在 Twitter 看到,剛剛在 Hacker News Daily 上的整理又看到:

老外在研究的時候發現這個密碼看起來夠長 (12 個字),而且也還算安全 (有英文與數字,看起來無意義),但卻發現被大量重複使用,而不只是單一帳號在用,就很好奇發生這是什麼東西...

對於台灣人來說應該是很熟悉了,這是注音輸入法的「我的密碼」:

出自維基百科的「File:Keyboard layout Zhuyin.svg

非拼音類的輸入法應該都會產生一樣的困惑...

當 credential 外洩時的處理方式...

昨天講到 Udacity 把 credential 放到 git repository 裡的方式 (參考「Udacity 管理 credential 的方式...」這篇),結果就看到另外一篇講當外洩時降低傷害的文章:「Leak Mitigation Checklist」。

裡面講的方法沒什麼特別的 (倒是花了不少篇幅在介紹各家的 credential 要怎麼重生),畢竟這是一份 checklist,只是要確保最低標準的步驟都應該要確認有做。

不過這兩篇放在一起看還蠻有趣的...

Udacity 管理 credential 的方式...

看到 Udacity 管 credential 的方式,可以用「我就是想把這些東西放到 Git 裡面管理啦」來解釋:「Three Simple Rules for Putting Secrets into Git」。

看了一下 Udacity 的架構,從 catalog-api.udacity.com 看起來應該是放在 AWSus-west-2 上?那麼不考慮使用 AWS 的 KMS 是什麼?或是退一步來說,連自架的 Vault 也不考慮的原因又是什麼?下面的 response 好像沒什麼人提出問題... 在不知道前提的情境下,選擇這樣的方法其實有點怪,2012 年成立的公司有這麼重的包袱嗎?

先看看就好 XD