AWS 推出 Amazon Route 53 Resolver DNS Firewall

長久以來的洞總算有比較好的方法補上了,AWS 推出了 Amazon Route 53 Resolver DNS Firewall:「Introducing Amazon Route 53 Resolver DNS Firewall」。

Route 53 Resolver 是 AWS 官方提供的 DNS Resolver,沒有特殊的設定的話通常會在 x.x.x.2 (/24 或是更大的網段),先前一直沒有辦法解決 data leak 的問題,也就是透過 DNS 把敏感資料從 private network 裡丟出去。

以前的作法是透過 security group 擋掉對 Route 53 Resolver 的流量 (或是透過 VPC 的 Firewall 擋),然後自己架設兩台 DNS resolver 過濾,現在 Route 53 Resolver 支援 DNS Firewall,提供 allowlist 與 blocklist 這兩個功能使用,總算是把這件事情解的比較乾淨了:

Route 53 Resolver DNS Firewall lets you create “blocklists” for domains you don’t want your VPC resources to communicate with via DNS. You can also take a stricter, “walled-garden” approach by creating “allowlists” that permit outbound DNS queries only to domains you specify. You can also create alerts for when outbound DNS queries match certain firewall rules, allowing you to test your rules before deploying for production traffic.

另外這次的 DNS Firwall 提供了兩組由 AWS 維護的清單讓人使用,包括了 malware 與 botnet:

Route 53 Resolver DNS Firewall offers two managed domain lists—malware domains and botnet command and control domains—enabling you to get started quickly with managed protections against common threats.

這樣省事多了...

Facebook 5.33 億筆個資外洩,以及 Mark Zuckerberg 的電話...

這兩天應該已經有很多其他媒體報導了 Facebook 5.33 億筆資料外洩的事情:「533 million Facebook users' phone numbers and personal data have been leaked online」。

據稱是用 2019 年的洞撈出來的,不過這份資料看起來也不是完整資料,舉個例子來說,台灣只有 73 萬筆左右,而且也少了很多地區,像是泰國就不在列表內...

另外一個比較特別的是,Mark Zuckerberg 的電話也在這次外洩資料裡面:「Mark Zuckerberg's phone number appeared among the leaked data of Facebook users, according to a researcher」,應該會換號碼了。

這包資料看起來會這陣子會很熱門...

還原被碼掉的 PEM 資訊 (SSH RSA key)

在「Recovering a full PEM Private Key when half of it is redacted」這邊看到的,起因是 _SaxX_ 幫客戶做滲透測試時找到客戶公開在網路上的 SSH key,然後他就碼掉一部分貼出來:

原圖是這樣,接下來就開始被還原 XD

首先是 OCR 的過程,被稱為是整個還原過程最難的一部分 (哭爸啊):

Ironically, this was the hardest part of the challenge. It took the longest time of all the steps and was the easiest to make errors in.

接下來就是解讀 PEM 檔的格式,可以藉此得到裡面的參數。

然後是套公式,窮舉運算裡面的值,可以看到迴圈 kp 只算了 365537,就推算出可能的 p

e = 65537
q = 0xc28871e8714090e0a33327b88acc57eef2eb6033ac6bc44f31baeac33cbc026c3e8bbe9e0f77c8dbc0b4bfed0273f6621d24bc1effc0b6c06427b89758f6d433a02bf996d42e1e2750738ac3b85b4a187a3bcb4124d62296cb0eecaa5b70fb84a12254b0973797a1e53829ec59f22238eab77b211664fc2fa686893dda43756c895953e573fd52aa9bb41d22306135c81174a001b32f5407d4f72d80c5de2850541de5d55c19c1f817eea994dfa534b6d941ba204b306225a9e06ddb048f4e34507540fb3f03efeb30bdd076cfa22b135c9037c9e18fe4fa70cf61cea8c002e9c85e53c1eaac935042d00697270f05b8a7976846963c933dadd527227e6c45e1
dp = 0x878f7c1b9b19b1693c1371305f194cd08c770c8f5976b2d8e3cf769a1117080d6e90a10aef9da6eb5b34219b71f4c8e5cde3a9d36945ac507ee6dfe4c146e7458ef83fa065e3036e5fbf15597e97a7ba93a31124d97c177e68e38adc4c45858417abf8034745d6b3782a195e6dd3cf0be14f5d97247900e9aac3b2b5a89f33a3f8f71d27d670401ca185eb9c88644b7985e4d98a7da37bfffdb737e54b6e0de2004d0c8c425fb16380431d7de40540c02346c98991b748ebbc8aac73dd58de6f7ff00a302f4047020b6cd9098f6ba686994f5e043e7181edfc552e18bce42b3a42b63f7ccb7729b74e76a040055d397278cb939240f236d0a2a79757ba7a9f09

for kp in range(3, e):
    p_mul = dp * e - 1
    if p_mul % kp == 0:
        p = (p_mul // kp) + 1
        if isPrime(p):
            print(f"Possible p: {p}")

後面就是跑驗證確認,就被打出來了...

Zoom 在分享螢幕時會有資料安全性問題

看到「Zoom Screen-Sharing Glitch ‘Briefly’ Leaks Sensitive Data」這篇,講 Zoom 在分享螢幕時的安全性問題,發現問題的德國資安團隊所寫的 security advisory 可以在「SYSS-2020-044.txt」這邊看到,對應的 CVE 號碼是 CVE-2021-28133

安全問題出在,分享者要分享某個應用程式的畫面,但有可能會先分享到其他畫面,再切回來:

However, “under certain conditions” if a Zoom presenter chooses to share one application window, the share-screen feature briefly transmits content of other application windows to meeting participants, according to German-based SySS security consultant Michael Strametz, who discovered the flaw, and researcher Matthias Deeg, in a Thursday disclosure advisory (which has been translated via Google).

而目前的版本還是有一樣的問題:

The current Zoom client version, 5.5.4 (13142.0301), for Windows is still vulnerable to the issue, Deeg told Threatpost.

這個問題是去年十二月就通報了,過了三個月沒有回應,所以團隊公開出來:

Disclosure Timeline:

2020-12-02: Vulnerability reported to manufacturer
2020-12-02: Manufacturer acknowledges receipt of security advisory
2020-12-02: Manufacturer asks for more information
2020-12-03: SySS provides more information concerning the security issue
2020-12-03: Manufacturer confirms reproducing the security issue in both the Windows and the Linux client and asks further questions
2020-12-04: SySS answers open questions
2020-12-04: Manufacturer responds and will look into the reported security issue
2021-01-21: SySS asks for status update
2021-02-01: SySS asks for status update
2021-03-18: Public release of security advisory

不知道什麼時候會修正

Zoom 的浮水印功能

Hacker News Daily 上看到 The Intercept 介紹了 Zoom 的浮水印功能,以及如果你要洩密的話要如何自保:「What You Should Know Before Leaking a Zoom Meeting」。這篇文章主要不是談 Zoom 之前被討論的那些問題,而就 Zoom 的浮水印功能來討論。

Zoom 支援 video watchmark 與 audio watchmark:

依照描述的兩個方式,看起來都不難破,但主要是要提醒記者,如果要放出線人提供的 Zoom 錄音或是錄影,要注意到裡面是否有 watchmark 導致線人的資訊被洩漏:

Journalists should also be wary of publishing raw audio leaked from Zoom meetings, particularly if the source is not sure whether audio watermarking was enabled or not.

翻了一下 GitHub 沒搜到有工具可以處理,這點可能要等人發展出來...

最近洩漏出來的 Intel 程式碼...

已經有不少新聞都有報導提到最近被丟出來的 Intel 程式碼:

這些程式碼都是需要簽 NDA 或類似的合約才能拿到,這次被丟出來可以看到不少東西... 發佈的人有提到可以搜尋一些「關鍵字」,像是 backdoor 這個:

然後結果還蠻有趣的,看起來這包 20GB 的檔案可以讓不少人研究一陣子...

EC2 的 Auto Scaling 增加了兩個功能

Amazon EC2Auto Scaling 增加了兩個功能,一個是 instance 可以有權重了:「Amazon EC2 Auto Scaling Now Supports Instance Weighting」,另外一個是可以設定 instance 活多久就要換一台:「Amazon EC2 Auto Scaling Now Supports Maximum Instance Lifetime」。

前面的 instance weighting 這個功能對於會混多種不同 family type 的情境會好用不少 (像是同時混用 {c3,c4,c5}.xlarge),可以讓設定上細緻一些,不然就只能以效能最低的那個類型規劃...

後面的 maximum instance lifetime 這個功能看起來可以拿來解各種 resource leak 的情境,而且現在 EC2 instance 是以秒計費,所以不用太擔心成本浪費太多的問題... 這樣不管是 memory leak 還是 /tmp 下暫存檔懶的清的問題,都可以很順利的逃避現實 XDDD

Nokia 釋出的 Memory Profiler

Rust 開發的 memory profiler,可以抓 memory leaking 與 memory fragmentation,然後宣稱效能影響也比較低:「A memory profiler for Linux」,有提供網頁界面,還蠻美觀的:

給的範例有兩行,一行是跑 profiler:

LD_PRELOAD=./libmemory_profiler.so ./your_application

另外一行是讀資料給 HTTP server:

./memory-profiler-cli server memory-profiling_*.dat

之後有機會抓漏時可以拿來用看看...

Python 上觀察 Memory Leak

Zendesk 的「Hunting for Memory Leaks in Python applications」這篇介紹了 memory_profiler 這個工具,可以比較長期的觀察記憶體使用量的問題。

首先是先看正常與疑似異常的分析:

然後可以拉出資料型態資訊:

這些資訊要找 memory leak 還是蠻粗糙的,但算是給了個方向,而且用起來算是簡單...

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

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

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

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