AS112 計畫

在「Cloudflare is joining the AS112 project to help the Internet deal with misdirected DNS queries」這邊看到的東西:「AS112 Project」,在維基百科上面也有條目:「Blackhole server」。

Cloudflare 宣佈 2022/12/15 參與 AS112 Project:

We are going to announce the AS112 prefixes starting December 15, 2022.

針對 private network 的反解 (像是 192.168.x.x 這些網段),目前的 NS RR 會丟到 IANA 的 blackhole server 上:

;; AUTHORITY SECTION:        86400   IN      NS        86400   IN      NS

這兩的 domain name 分別是 與。

而 IANA 的 blackhole server 的負荷愈來愈重,所以就有了透過 anycast 打散負荷的想法,也因為在發 anycast 時的 ASN 是 112,後來也就變成了 AS112 計畫,在 RFC 7534 裡面解釋了要怎麼做:「AS112 Nameserver Operations」。

另外在 AS112 Project 的網站上也有提到 anycast 的範圍:

The address blocks are and 2620:4f:8000::/48 and its origin AS is 112.

昨天 HiNet 線路連到 AS112 的 192.175.48.x 網段會丟到日本的 WIDE,剛剛看發現已經是 Cloudflare 在台灣的點了:

;; ANSWER SECTION:    604800  IN      TXT     "Cloudflare DNS, TPE"    604800  IN      TXT     "See for more information."

但如果是用 Google Public DNS 查詢的話則是會到 STUIX,先前也有在其他地方看到這個有趣的組織:

;; ANSWER SECTION:    300     IN      TXT     "Taiwan Digital Streaming Co. with STUIX"    300     IN      TXT     "Taipei, TW"    300     IN      TXT     "Unicast IP:"    300     IN      TXT     "See for more information."

回過頭來看這次 Cloudflare 的加入,他們手上的機房與點都很多,這次跳進去看起來會分擔掉不少其他節點的 loading。

但另外隱憂 privacy 的考量,他們手上等於是可以看到一堆 invalid DNS query log...


原文是講滲透測試的前置作業,需要將某個特定 domain 下的主機名稱掃出來:「A penetration tester’s guide to sub-domain enumeration」。

最直接的還是 DNS zone transfer (AXFR),如果管理者沒設好 DNS server 的話,這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。


應該有人可以提到所有的東西再寫成程式 XD

U2F Security Key 產品測試?

Adam Langley 的「Testing Security Keys」這篇測試了不少有支援 U2F Security Key 的產品,這邊作者是以 Linux 環境測試。

tl;dr:在 Linux 環境下,除了 Yubico 的產品沒問題外,其他的都有問題... (只是差在問題多與少而已)

Yubico 的沒找到問題:

Easy one first: I can find no flaws in Yubico's U2F Security Key.

VASCO SecureClick 的則是 vendor ID 與 product ID 會跑掉:

If you're using Linux and you configure udev to grant access to the vendor ID & product ID of the token as it appears normally, nothing will work because the vendor ID and product ID are different when it's active. The Chrome extension will get very confused about this.

Feitian ePass 的 ASN.1 DER 編碼是錯的:

ASN.1 DER is designed to be a “distinguished” encoding, i.e. there should be a unique serialisation for a given value and all other representations are invalid. As such, numbers are supposed to be encoded minimally, with no leading zeros (unless necessary to make a number positive). Feitian doesn't get that right with this security key: numbers that start with 9 leading zero bits have an invalid zero byte at the beginning. Presumably, numbers starting with 17 zero bits have two invalid zero bytes at the beginning and so on, but I wasn't able to press the button enough times to get such an example. Thus something like one in 256 signatures produced by this security key are invalid.

Thetis 根本沒照 spec 走,然後也有相同的 ASN.1 DER 編碼問題:

With this device, I can't test things like key handle mutability and whether the appID is being checked because of some odd behaviour. The response to the first Check is invalid, according to the spec: it returns status 0x9000 (“NO_ERROR”), when it should be 0x6985 or 0x6a80. After that, it starts rejecting all key handles (even valid ones) with 0x6a80 until it's unplugged and reinserted.

This device has the same non-minimal signature encoding issue as the Feitian ePass. Also, if you click too fast, this security key gets upset and rejects a few requests with status 0x6ffe.

U2F Zero 直接 crash 沒辦法測 XDDD:

A 1KiB ping message crashes this device (i.e. it stops responding to USB messages and needs to be unplugged and reinserted). Testing a corrupted key handle also crashes it and thus I wasn't able to run many tests.

KEY-ID (網站連 HTTPS 都沒上...) / HyperFIDO 也有編碼問題但更嚴重:

The Key-ID (and HyperFIDO devices, which have the same firmware, I think) have the same non-minimal encoding issue as the Feitian ePass, but also have a second ASN.1 flaw. In ASN.1 DER, if the most-significant bit of a number is set, that number is negative. If it's not supposed to be negative, then a zero pad byte is needed. I think what happened here is that, when testing the most-significant bit, the security key checks whether the first byte is > 0x80, but it should be checking whether it's >= 0x80. The upshot is the sometimes it produces signatures that contain negative numbers and are thus invalid.

所以還是乖乖用 GitHub 帳號買 Yubico 吧...

伊朗透過 BGP 管制網路的手段影響其他國家網路...

Dyn (之前被 DDoS 打爆,過一陣子被 Oracle 買去的那個 Dyn) 的這篇「Iran Leaks Censorship via BGP Hijacks」講到他們偵測到伊朗透過 BGP hijack 管制網站的問題。

前陣子伊朗透過 private ASN 放了 出來,影響到其他國家:

Last week, Iranian state telecom announced a BGP hijack of address space ( hosting numerous pornographic websites.

由於這段 IP address 在 internet 上是以 在放,就因為 /24 優先權比較高而被蓋過去影響到全世界...

然後過了幾天,開始攻擊蘋果的 iTunes 服務,不過這次是以 /32 放出來。由於大多數收的最小單位是 /24,這次的影響沒有上次大:

In addition, TIC announced BGP hijacks for 20 individual IPs associated with Apple’s iTunes service. These too were carried by Omantel to the outside world, albeit with a smaller footprint due to the fact that BGP routes for /32’s typically don’t propagate very far.

這看得出來 routing 在 internet 上還是非常脆弱...