Tag Archives: number

MTR 看每個點的 AS number 或是地區資訊

跟「Mac 上讓 SSH 走 Socks5 的方式」這邊也有點關係,在泰國時測試發現 MTR 可以除了標準的 traceroute 結果外,還可以另外拉出 AS number 或是地區資訊。雖然不一定準 (因為是靠 IP address 查的),但可以很方便取得這些資料加減參考用。

-z 可以拉出 AS number (雖然 manpage 裡面不知道在搞什麼 XDDD):

       -z, --aslookup
              MISSING

另外一個是 -y,也沒寫要怎麼用,但因為是標 n 所以可以猜是數字。實際測試可以看出跟 GeoIP 套件似乎有些相關...

-y 1 是 IP network 區段 (像是 168.95.0.0/16),而 -y 2 則是地區資訊 (像是 TW 或是 US),-y 3 則是哪個 NIC 管的 (像是 apnic),-y 4 是更新日期:

       -y n, --ipinfo n
              MISSING

配合 -b 可以同時看 hostname 與 IP address,這樣資訊就蠻完整的了。另外在 Mac 上的 Homebrew 編出來的 MTR 測不出這些功能,我暫時沒花時間去追,這邊主要都是拿 Ubuntu 上的版本測試的...

找數列的平均值

2016 年的文章,不過算是經典的題目,所以最近又冒出來了。要怎麼找數列的平均值:「Calculating the mean of a list of numbers」。

You have a list of floating point numbers. No nasty tricks - these aren’t NaN or Infinity, just normal “simple” floating point numbers.

Now: Calculate the mean (average). Can you do it?

你有一串浮點數 (沒有 NaN 與 Infinity),要怎麼找出平均值。要考慮的包括:

  • 第一個要處理的就是設計演算法時各種會 overflow 的情況。
  • 降低誤差。
  • 合理的計算量。

好像很適合拿來 data team 面試時互相討論的題目?因為「平均值」是個商業上本來就有意義的指標,而且從 time-series events 灌進來的資料量有機會產生各種 overflow 情境,或是精確度問題,所以這個問題其實是個在真實世界上會遇到的情境。

想了一下,如果是 integer 的確是簡單很多 (可以算出正確的值),但如果是 float 類型真的難很多:

It also demonstrates a problem: Floating point mathematics is very hard, and this makes it somewhat unsuitable for testing with Hypothesis.

馬上想到的地雷是在 IEEE 754 的 float 世界裡,2^24 + 1 還是 2^24

#include <math.h>
#include <stdio.h>

int main(void)
{
    int i;
    float a;

    for (i = 0; i < 32; i++) {
        a = pow(2, i);
        printf("2^%d     = %f\n", i, a);

        a += 1;
        printf("2^%d + 1 = %f\n", i, a);
    }
}

然後在這邊可以看出差異:

2^23     = 8388608.000000
2^23 + 1 = 8388609.000000
2^24     = 16777216.000000
2^24 + 1 = 16777216.000000

PHP 數字與字串比較的提案

在「Links: February 2019」這邊看到 PHP 社群的提案,想要改善數字與字串比較的結果:「PHP RFC: Saner string to number comparisons」。

他給了一個經典的範例:

$validValues = ["foo", "bar", "baz"];
$value = 0;
var_dump(in_array($value, $validValues));
// bool(true) WTF???

原因是 in_array()== 而非 ===,所以就噴了... 而提案我看了還是覺得不行啊,看看會怎麼改吧 :o

Ethereum Smart Contracts 裡的 PRNG

現代密碼學的安全性有很大一塊是基於亂數產生器 (RNG) 非常難被預測。如果這個前提不成立的話,利用亂數產生器產生出來的各種資訊都會被預測出來 (尤其是 Private Key)。

但真正的 RNG 需要靠硬體支援,而且產生速度很慢,一般都會使用 PRNG (Pseudorandom number generator) 產生。也就是「看起來」很亂的亂數產生器。

PRNG 通常是指在統計學上通過許多測試,像是在多種測試都是 Discrete uniform distribution,不需要防止有惡意人,可以從產生出的 PRNG 的值而推導出後續結果的用途。

在「Predicting Random Numbers in Ethereum Smart Contracts」這篇裡面,作者列出了一堆實做 Ethereum Smart Contracts 卻誤用 PRNG 的行為。

文章裡提到的問題都是因為 PRNG 拿著可被預測的資訊當作 entropy source (e.g. seed),而且提出來的範例都是拿 block 本身或衍生的資訊 (像是 block 的 hash) 來用:

  • PRNGs using block variables as a source of entropy
  • PRNGs based on a blockhash of some past block
  • PRNGs based on a blockhash of a past block combined with a seed deemed private
  • PRNGs prone to front-running

然後列了大量的程式碼當例子,建議有需要接觸的人看過一次,或是有時間的人都值得看這些負面範例... XDDD

不過作者在文章裡面也給了一堆有問題的方法,像是從外部網站取得亂數之類的 XDDD

正確的方法是使用 CSPRNG (Cryptographically secure pseudorandom number generator),這是專門設計給密碼學用的 PRNG。

CSPRNG 有幾種方法可以取得:

  • 在大多數的程式語言內都有對應的 library 可以用,另外在比較近代的瀏覽器內 (如果問 IE 的話,是 11+),可以透過 RandomSource.getRandomValues() 得到。
  • 如果打算自己搞底層而需要直接取得 CSPRNG 的產出,在 Unix-like 的環境下可以透過 /dev/urandom 取得,在 Microsoft Windows 下則可以透過 CryptGenRandom 取得。

別學作者那邊奇怪方法啊 XDDD

各家 Session Replay 服務對個資的處理

Session Replay 指的是重播將使用者的行為錄下來重播,市面上有很多這樣的服務,像是 User Replay 或是 SessionCam

這篇文章就是在討論這些服務在處理個資時的方式,像是信用卡卡號的內容,或是密碼的內容,這些不應該被記錄下來的資料是怎麼被處理的:「No boundaries: Exfiltration of personal data by session-replay scripts」,主要的重點在這張圖:

後面有提到目前防禦的情況,看起來目前用 adblock 類的軟體可以擋掉一些服務,但不是全部的都在列表裡。而 DNT 則是裝飾品沒人鳥過:

Two commonly used ad-blocking lists EasyList and EasyPrivacy do not block FullStory, Smartlook, or UserReplay scripts. EasyPrivacy has filter rules that block Yandex, Hotjar, ClickTale and SessionCam.

At least one of the five companies we studied (UserReplay) allows publishers to disable data collection from users who have Do Not Track (DNT) set in their browsers. We scanned the configuration settings of the Alexa top 1 million publishers using UserReplay on their homepages, and found that none of them chose to honor the DNT signal.

Improving user experience is a critical task for publishers. However it shouldn’t come at the expense of user privacy.

The DUHK Attack:因為亂數產生器的問題而造成的安全漏洞

Bruce Schneier 那邊看到的:「Attack on Old ANSI Random Number Generator」,攻擊的網站在「The DUHK Attack」,論文在「Practical state recovery attacks against legacy RNG implementations (PDF)」。

攻擊的對象是 ANSI X9.31 Random Number Generator:

DUHK (Don't Use Hard-coded Keys) is a vulnerability that affects devices using the ANSI X9.31 Random Number Generator (RNG) in conjunction with a hard-coded seed key.

然後攻擊的對象是 FortinetFortiOS

Traffic from any VPN using FortiOS 4.3.0 to FortiOS 4.3.18 can be decrypted by a passive network adversary who can observe the encrypted handshake traffic.

如果照說明的只到 4.3.18,那麼去年 11 月更新的 4.3.19 (參考「FortiOS 4.3.19 Release Notes」) 應該是修正了?不過裡面沒翻到類似的資料,是剛好把 RNG 換掉了嗎?

ROCA:Infineon Technologies 的 RSA 實做問題

最近的另外一個大包,不過這包是 Infineon Technologies 在實做 RSA 算法時的問題,倒不是 RSA 算法本身有問題。之所以會「大」是因為有太多人用了:「ROCA: Vulnerable RSA generation (CVE-2017-15361)」。

起因於 Infineon Technologies 在產生 key 時的組合有限,於是要猜測的 keyspace 小很多。

以研究者的估算,可以看出 CPU year 都被大幅減少了,都是屬於「可行」的範圍:

The time complexity and cost for the selected key lengths (Intel E5-2650 v3@3GHz Q2/2014):

512 bit RSA keys - 2 CPU hours (the cost of $0.06);
1024 bit RSA keys – 97 CPU days (the cost of $40-$80);
2048 bit RSA keys – 140.8 CPU years, (the cost of $20,000 - $40,000).

而且這邊是用 CPU year 估算,如果考慮 FPGA 加速計算,應該會短更多...

另外從發現到公開的時間線也拉得很長,可以看到中間一直在找解決方案:

2nd of November 2017 - Presentation of all details at the ACM CCS conference (to come)
16th of October 2017 - The initial version of the public disclosure published
May to October 2017 - Cooperation with the manufacturer and other affected parties to help evaluate and mitigate the vulnerability
1st of February - The vulnerability disclosed to Infineon Technologies AG
End of January - The vulnerability found

過一陣子就會去 conference 上報告了...

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

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

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

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

由於這段 IP address 在 internet 上是以 99.192.128.0/17 在放,就因為 /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 上還是非常脆弱...

信用卡的先天缺陷造成盜刷問題

在「Guessing Credit Card Security Details」這邊看到的攻擊手法,基本上無解,除非信用卡的網路交易也全面改成使用晶片...

手法其實很簡單,就是先算出一個合法的卡號,然後分兩階段攻擊取得資訊:

  • 先去找數家只需要「卡號 + 日期」的網站,用暴力法踹出日期 (假設五年就是 60 次)。
  • 再去找數十家需要「卡號 + 日期 + CVV2」的網站,用暴力法踹出 CVV2 (1000 次)。

所以 1060 次就擺平了... 就算所有網站都需要 CVV2,也是 60000 次的嘗試而已 (找數千個網站來踹),算是完全可行的方案。而目前只能靠 workaround 來防止,像是需要多輸入姓名與地址之類的資訊來擋...