[校園] 教你用電子投票 NTUvote102-2 寫 Hello World
雖然小魯的專長不是大型網站開發或資安滲透測試,
但是畢竟還是對資訊有一點興趣,在大三以後接觸了不少阿宅小知識,
對於今次的所謂「電子投票」(嗎?) 的許多爭議,潛在水裡看了看
覺得應該可以對該系統本身的設計、程式架構、安全性的眾多問題提出一些意見。
首先是看個影片。寫程式的阿宅總會想套用老梗「 hello world 」在初見的新玩意兒上。
我們可不可以請投票系統 hello world 一下呢? (註: 該漏洞在投票前就已修正)
http://vimeo.com/96702478
就如影片當中所顯示的,只要投票者有心,並且他能在短時間內想辦法用 VPN
內網的裝置 (例如投票的平板) 快速輸入大約 170 characteres 的魔法咒語,
就可讓遠端伺服器執行任何你想要的指令。(例如 rm -Rf . 之類的)
這裡只是為了展示概念而簡單地 touch hello-world 一下,不需多做解釋;
總之在影片左上角可以看到 git repository 內容可以成功地被我們投票者修改。
不過 real world attackers 想要做的當然遠遠不止這些,
所有該 process uid 可以做的事情咱們都能做到... 這就要看人們的想像力了。
至於為什麼這個系統會有這樣的問題呢?鄙人認為有數個因素,在此列出幾小點。
1. 撰寫整個網站沒有善加利用已經存在的 Web development frameworks
想要使用 MVC ,但是對 PHP 不是太熟悉的話,就不應該徒手去刻。
自己刻的話,各種安全性議題的 edge case 要考慮全面是很辛苦的。
2. 系統設計看起來有許多邏輯上的問題、怪異之處
舉例來說「身份認證」不應該是隨便想一套算法,套個 MD5 就可以 work 的,
應直接找現有的方案來套用。數學系及資訊系都有人對資訊安全、密碼技術相當了解,
遇到問題時向他們咨詢也是需要的。
舉例來說,像是影片中的攻擊,之所以成立,
應該是因為有一個像這樣的奇怪的判斷條件可以被 bypass with arbitrary code:
f( some_constant || user_input_key1 ) === user_input_key2
其中 f 是一個 cryptographically insecure one-way function
這裡只是很簡單地描述而已,實際狀況比較複雜,可以直接參照 code 。
使用者輸入的這個 key1 值會一層層逐漸傳遞到投票系統的深處,最終被 git commit
如果使用者可以改 key1 的話,就會因為其他部分的疏忽,導致任意代碼執行的漏洞。
但是,為什麼使用者改了 key1 以後這個判斷條件還能成立?
這是因為 some_constant 不是未知的數值,
任何人只要計算 f() 馬上就可以推知 key2 了,這樣子檢查 key2 就沒有任何意義。
3. 這個系統的開發可能沒有得到足夠多人的協助、咨詢、review
如果有足夠多的 reviewer 的話,應該就不會允許那麼多 bad practice 四散各地,
該份程式碼有非常多潛在問題,不只是上面影片中提到的 exec() 問題而已。
允許 bad practice 是很不好的,今天程式跑起來沒有問題,但是隔幾個月後,
陸陸續續修改各個元件了,還能保證以後不會引爆出別的更嚴厲的漏洞嗎?
4. 這樣子的系統其實根本不算是合理的「電子投票」
現在我們看到的只是一個有電子設備輔助的投票流程,
而且這個「電子輔助」好像沒有帶給我們更多的方便。
如果只是想要咬文嚼字地片面解釋說這玩意兒就是「電子投票」當然也是可以...
但是一個正常運作的「電子投票」需要有一些良好的 "provable" properties
- 某些人想要作弊?數學定理告訴我們他做不到。
- 想要驗自己的票?可以。你可以確認自己的票是否正確地被計入。
- 想要驗他人的票?多給一些條件以後,這當然也有辦法做到。
如果一個系統運行的正確性,有很多部分可以被「驗證」的話,就更能被大家接受。
而不是完全黑箱,把所有奢求的正確性都壓在一個名為「相信選舉主辦方」的籃子裡。
這樣子的「正確性」是脆弱而難以被長時間考驗的。
其實最理想的情況下,應當是使用者直接安裝軟體,在手機/電腦上直接參與投票,
請計中(orz)協助線上身份認證,或者善用 NFC 學生證悠遊卡來幫忙投票的過程。
一個好的 protocol 可以讓使用者無法在他的終端作弊,而主辦方也沒有辦法作弊。
當然了,這是一個浩大的工程,要請更多專家來幫忙才行,並不是短時間可以做到的。
5. 開放原始碼的程度其實不夠完整,普通人難以直接參與其中
只有 GitHub 上這一部分的 php 程式碼,
對於普通的 programmer 來說,還是難以幫忙「開發」、「測試」的。
應加上如何部署一台伺服器的說明、資料該如何生成、資料庫應該要有怎樣的結構等。
降低協助測試的門檻,才會有更多志願者來幫忙開發。
辛苦的核心開發人員也就不用焦頭爛耳修 bug 寫新 features 了。
如果這個系統以後還想要被使用,必定是要經過「砍掉重練」等級的大幅度更動。
不過任何的新制度也都是如此,剛開始會衝突、有異議,
必須仔細接納不同的意見,經逐步地修正、成熟化,最終才能被廣泛地接受。
如果還有許多爭議、不同的聲音時,就表示有一些根本上的問題,
所以人們才沒有被說服,所以該制度、系統就還需要修正。
不過無論如何,我們都還是由衷地感謝許多台前台後參與、幫忙的人,
因為有你們默默地無償付出,我們才能夠享受到各式各樣的福利。謝謝你們!
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.112.30.44
※ 文章網址: http://www.ptt.cc/bbs/NTU/M.1401292521.A.34F.html
推
05/28 23:59, , 1F
05/28 23:59, 1F
推
05/29 00:00, , 2F
05/29 00:00, 2F
推
05/29 00:03, , 3F
05/29 00:03, 3F
推
05/29 00:05, , 4F
05/29 00:05, 4F
推
05/29 00:05, , 5F
05/29 00:05, 5F
推
05/29 00:05, , 6F
05/29 00:05, 6F
推
05/29 00:06, , 7F
05/29 00:06, 7F
推
05/29 00:07, , 8F
05/29 00:07, 8F
推
05/29 00:07, , 9F
05/29 00:07, 9F
推
05/29 00:10, , 10F
05/29 00:10, 10F
推
05/29 00:10, , 11F
05/29 00:10, 11F
推
05/29 00:10, , 12F
05/29 00:10, 12F
推
05/29 00:12, , 13F
05/29 00:12, 13F
推
05/29 00:13, , 14F
05/29 00:13, 14F
推
05/29 00:14, , 15F
05/29 00:14, 15F
推
05/29 00:15, , 16F
05/29 00:15, 16F
推
05/29 00:16, , 17F
05/29 00:16, 17F
推
05/29 00:17, , 18F
05/29 00:17, 18F
推
05/29 00:17, , 19F
05/29 00:17, 19F
推
05/29 00:18, , 20F
05/29 00:18, 20F
推
05/29 00:18, , 21F
05/29 00:18, 21F
推
05/29 00:18, , 22F
05/29 00:18, 22F
推
05/29 00:23, , 23F
05/29 00:23, 23F
推
05/29 00:27, , 24F
05/29 00:27, 24F
推
05/29 00:28, , 25F
05/29 00:28, 25F
推
05/29 00:31, , 26F
05/29 00:31, 26F
推
05/29 00:35, , 27F
05/29 00:35, 27F
推
05/29 00:35, , 28F
05/29 00:35, 28F
推
05/29 00:35, , 29F
05/29 00:35, 29F
推
05/29 00:37, , 30F
05/29 00:37, 30F
推
05/29 00:45, , 31F
05/29 00:45, 31F
推
05/29 00:46, , 32F
05/29 00:46, 32F
推
05/29 00:51, , 33F
05/29 00:51, 33F
推
05/29 00:58, , 34F
05/29 00:58, 34F
推
05/29 01:00, , 35F
05/29 01:00, 35F
推
05/29 01:06, , 36F
05/29 01:06, 36F
推
05/29 01:07, , 37F
05/29 01:07, 37F
→
05/29 01:13, , 38F
05/29 01:13, 38F
推
05/29 01:14, , 39F
05/29 01:14, 39F
還有 60 則推文
還有 6 段內文
→
05/29 18:23, , 100F
05/29 18:23, 100F
→
05/29 18:24, , 101F
05/29 18:24, 101F
→
05/29 19:58, , 102F
05/29 19:58, 102F
→
05/29 19:58, , 103F
05/29 19:58, 103F
→
05/29 19:59, , 104F
05/29 19:59, 104F
→
05/29 20:01, , 105F
05/29 20:01, 105F
→
05/29 20:01, , 106F
05/29 20:01, 106F
→
05/29 20:04, , 107F
05/29 20:04, 107F
推
05/29 20:04, , 108F
05/29 20:04, 108F
→
05/29 20:04, , 109F
05/29 20:04, 109F
→
05/29 20:04, , 110F
05/29 20:04, 110F
→
05/29 20:05, , 111F
05/29 20:05, 111F
→
05/29 20:05, , 112F
05/29 20:05, 112F
→
05/29 20:07, , 113F
05/29 20:07, 113F
→
05/29 20:07, , 114F
05/29 20:07, 114F
→
05/29 20:08, , 115F
05/29 20:08, 115F
→
05/29 20:08, , 116F
05/29 20:08, 116F
→
05/29 20:10, , 117F
05/29 20:10, 117F
→
05/29 20:11, , 118F
05/29 20:11, 118F
→
05/29 20:12, , 119F
05/29 20:12, 119F
→
05/29 20:12, , 120F
05/29 20:12, 120F
→
05/29 20:15, , 121F
05/29 20:15, 121F
→
05/29 20:15, , 122F
05/29 20:15, 122F
→
05/29 20:16, , 123F
05/29 20:16, 123F
→
05/29 20:16, , 124F
05/29 20:16, 124F
yangwen5301 您好,謝謝你不吝於提供多方面的看法、討論。
關於「網路開放性」會對「安全程度」直接造成程度上的影響,你的看法是完全正確的。
如果,
存在有兩個系統,一個擺在開放網路上,一個擺在特定區域網路內,
他們能夠提供「相同的功能」,而且「理論上」他們「同樣安全」。
那麼,我們絕對就應該採用後者、區域網路內的那一個系統,
因為它的 attacking surfaces 較少。
然而一個合理的電子投票系統,終究要有一些 public API ,這些必定要讓大家可以
access 的 endpoints 就要愈簡單明瞭愈好。如你所說的,程式語言應撰寫得簡單易讀。
而且這種 public API 處,只要是會接受 input data ,就該嚴格地過濾、審視才行。
而其他只跟 server 有關的內部運算,當然就應該全面地只允許內網的存取,根本就
不必、也不應該公開。這是 common sense。愈是減少一個系統 publicly accessible 的
那些使用者不需存取的部分,這個系統就愈不容易出包。
這時候就可以被問一個問題:
那為什麼電子投票系統的主辦方『終究要有一些 public API 』呢?
因為實務上,就是幾乎沒有「所有計算都在區網內完成」這樣子的「多方」可信賴系統。
此處的重點不是區網、或公網。重點是一個協議的完成需要許多步驟,
這些步驟不可以完全只由「某一方」(例如選舉主辦方)就可以做到。
我們至少還是要有別的「信賴的基礎」才行。
例如一張晶片卡上的密碼運算、或者電腦上數位簽章的生成。
這個額外的「信賴」,是不可以只用「他人的」計算平台就做到的。
舉例來說,現實世界最傳統的身份驗證也許是簽名加蓋章。
王小明拿起一張合約以後,必須要「由他自己」來完成「簽字」與「蓋章」,
接著才會把這一張紙放進這個 blackboxed system 內,讓它去做別的事情。
這個櫃檯、這個接口就是王小明作為使用者所需要的「public API」。
反過來說,王小明走到服務人員櫃檯處,只經過簡單地寒暄問暖,就由服務人員來
單方面地就能夠「代替他」產生『此人是王小明,王小明今天想要轉帳...』之斷言。
那這個系統就沒有 (不需要) 任何實質上的 public API 。只要它想要,這個官方
它什麼都可以自己單方面地就做到。今天我們簡易版的電子投票其實有點像是這樣。
→
05/29 20:20, , 125F
05/29 20:20, 125F
→
05/29 20:21, , 126F
05/29 20:21, 126F
→
05/29 20:21, , 127F
05/29 20:21, 127F
你好,在嚴肅地密碼分析一個系統的安全性、在制定 threat model 時,就會把你提到的
『終端的軟硬體被 compromised/hijacked (到什麼程度) 時會對安全造成怎樣的影響?』
這個問題定清楚了。
我們應該要採取那些,就算一個使用者的終端裝置(作業系統、瀏覽器)被破解到某程度
也不會影響安全性的協定。
而且要注意的是,值得被考慮 threats 必須要合理,不能無限上綱而忽略了邏輯。
舉例來說,如果一個使用者的瀏覽器被置換了、或者一個裝置上的作業系統被 root 了,
那「這一個人」就已經沒救了,我們根本不需要考慮他個人投票到底還有沒有隱私、
還能不能正常地運行,因為他使用這台電腦不管做什麼事情,都可以被第三隻手操弄;
這就像是一個人想要向一個暗戀已久的女生告白, (人性就是想要上網
但是他性格太害羞,就找他的好朋友來幫忙傳話, (但因為人類無法讀懂電磁波/
電壓,所以就找電腦幫忙
他和這個女孩子之間所有的「通信」 (想要上網做任何事情
都是經由這位親切的好朋友之手。 (都經由這台電腦/瀏覽器
如果有一天,這個人不再是好朋友, (如果這電腦已經被植木馬...
那這個單相思的男孩是否能再與該女孩子建立良好的友誼,就已經不值得一談了。
我隨性亂想的比喻也許不適當,但是這應該勉強地有表達出那個意境。
推
05/29 20:50, , 128F
05/29 20:50, 128F
※ 編輯: concise (140.112.30.44), 05/29/2014 21:16:11
※ 編輯: concise (140.112.30.44), 05/29/2014 21:23:53
→
05/29 21:52, , 129F
05/29 21:52, 129F
→
05/29 21:52, , 130F
05/29 21:52, 130F
→
05/29 21:52, , 131F
05/29 21:52, 131F
→
05/29 21:53, , 132F
05/29 21:53, 132F
→
05/29 21:53, , 133F
05/29 21:53, 133F
→
05/29 22:00, , 134F
05/29 22:00, 134F
→
05/29 22:00, , 135F
05/29 22:00, 135F
推
05/31 01:31, , 136F
05/31 01:31, 136F