Adjust：SDK偽造 開源與閉源

借由查看應(yīng)用通過歸因SDK所發(fā)送的數(shù)據(jù)和歸因公司服務(wù)器中的數(shù)據(jù)，欺詐者就能決定他們需要發(fā)送什么信息以“欺騙”歸因公司來接受他們的偽造數(shù)據(jù)。一旦成功，欺詐者便可以創(chuàng)建無限量、看似真實(shí)的用戶和應(yīng)用內(nèi)事件，甚至無需在任何手機(jī)上運(yùn)行實(shí)際的應(yīng)用。

如今的欺詐者可以得到真實(shí)的設(shè)備ID，這意味著，除非您使用了加密簽名來確保數(shù)據(jù)是從應(yīng)用中發(fā)送的，否則他們產(chǎn)生的虛假數(shù)據(jù)看起來就如同真實(shí)數(shù)據(jù)一般。

正因?yàn)锳djust SDK是開源的，下面的問題更值得我們深究：

如何保護(hù)我們用來驗(yàn)證請求的代碼，不會輕易遭他人讀取并用來復(fù)制其行為？

Adjust之所以提供開源SDK，是因?yàn)槲覀兇_信客戶有權(quán)了解他們的應(yīng)用中發(fā)生了什么。除此之外，開源SDK促使我們與客戶的合作，創(chuàng)建市場上最穩(wěn)定且不會崩潰的SDK。事實(shí)上，歸因SDK應(yīng)該實(shí)現(xiàn)開源化的原因有很多，我們在之前的文章中已有所著墨。

Adjust SDK如何保證安全？

為了使用Adjust進(jìn)行跟蹤，客戶需要先將Adjust SDK集成到他們的應(yīng)用中。但是為了保護(hù)我們的客戶免受偽造影響，我們還要求客戶另外下載一個(gè)單獨(dú)的庫（library），并將其插入Adjust SDK。如果沒有這個(gè)庫，SDK并不安全，而我們也不會接受來自它的數(shù)據(jù)。

此庫可以創(chuàng)建加密簽名，而該簽名將附加到從SDK發(fā)送的每個(gè)數(shù)據(jù)請求中。它可以防御所有已知的攻擊方法，并由我們的安全專家團(tuán)隊(duì)不斷更新。每個(gè)庫都是不同的，這意味著如果一個(gè)應(yīng)用受到攻擊，相同的攻擊方法不會在世界上的任何其他應(yīng)用上起作用。此外，我們的安全團(tuán)隊(duì)會持續(xù)更新該庫，因此任何破壞安全性的新嘗試都將很快失效。

庫的代碼是隨機(jī)生成的，之后經(jīng)過特殊的編譯過程，使攻擊者無法對庫進(jìn)行反向工程以讀取代碼。

其他SDK是否更加安全？

大多數(shù)其他歸因SDK都是閉源的，不會向使用它們的客戶顯示其代碼，但這是否使它們更加安全？

“答案是并不會。”

在我們對SDK偽造的研究中，我們檢查了市場中的閉源歸因SDK，以了解它們在沒有加密簽名的情況下的安全性。遺憾的是，我們發(fā)現(xiàn)在每個(gè)案例中，這些SDK用來簽署數(shù)據(jù)請求的函數(shù)都能非常輕易地以人類可讀的形式提取，因此要攻破它是輕而易舉。

實(shí)際上，對于某些SDK，我們的研究人員只花了幾分鐘就能找到并破解它們的簽名功能——也就是說SDK的保護(hù)在短短的時(shí)間內(nèi)便被完全破除。這會導(dǎo)致非常嚴(yán)重的后果，因?yàn)橐坏┕粽哌@樣做，他們就可以使用該簽名來使虛假數(shù)據(jù)看起來完全真實(shí)。簡而言之，攻擊者可以輕松欺騙所有現(xiàn)行的閉源解決方案。

客戶插入到SDK的自定義庫里，并不包含歸因SDK的全部函數(shù)，只包含防止偽造所必須的相關(guān)函數(shù)。這意味著我們可以用完全不同的方式編寫、編譯和保護(hù)它。

出于安全考量，我們無法透露用于保護(hù)庫的所有方法，但是我們很樂意為客戶與我們的網(wǎng)絡(luò)安全專家之間連線，并提供進(jìn)一步的解釋?？偠灾?，保護(hù)開源SDK的安全性是絕對可行的，另一方面，閉源SDK不會遭受偽造的說法也是不正確的。