題:
Twitter和GitHub如何確保它們未被黑客入侵?
Kepotx
2018-05-04 13:11:49 UTC
view on stackexchange narkive permalink

昨天,Twitter 宣布,他們最近發現了一個錯誤,該錯誤在內部日誌中存儲了未公開的密碼。最近,Github也有一個類似錯誤。在這兩種情況下,他們都聲稱沒有人可以訪問這些文件。

Twitter:

我們已經修復了該錯誤,我們的調查沒有發現被破壞或濫用的跡象。再次。

同樣,儘管我們沒有理由相信密碼信息曾經離開過Twitter系統或被任何人濫用,但是您可以採取一些步驟來幫助我們保持您的身份帳戶安全:

GitHub:

該公司表示,純文本密碼僅向少數訪問這些日誌的GitHub員工公開。該公司表示,沒有其他GitHub用戶看到用戶的明文密碼。

GitHub表示,它在例行審核期間發現了錯誤,並明確表示其服務器未被黑客入侵。

請注意,GitHub並未受到任何形式的黑客攻擊或破壞。

Twitter和GitHub如何確保他們沒有遭到任何形式的黑客入侵或入侵?正在破壞服務器並讀取/複製文件的人是否總是留下痕跡?

Twitter的聲明實際上“沒有顯示出違反的跡象”,這意味著如果有人在那裡,則沒有任何跡象(這可以從一堆不同的日誌源中得出,這些日誌源查看與該計算機之間的連接,用戶有權訪問機器,等等)。
他們沒有聲明他們確定自己沒有被黑客入侵。他們說,他們沒有被黑客入侵的證據,但是缺少證據並不意味著沒有被黑客入侵-他們非常明智地聲稱自己沒有被黑客入侵。
關於此問題的最新文章:[“不可能證明您的筆記本電腦未被黑客入侵。”](https://theintercept.com/2018/04/28/computer-malware-tampering/)
在這裡,“被盜”甚至不是主要的風險類別。某些具有合法訪問權限的Twitter員工可以完全未經任何未經授權的滲透而竊取這些內容。實際上,幾乎可以肯定這是一開始就發現的。
您能否指出這些消息的哪些部分向您表明,他們“ **確定**”密碼未受到破壞?
正如Anders在他的良好回答中所說,@Bakuriu表示GitHub的詞彙非常明確,但Twitter的不確定性要高得多。也許我不應該在“ **確定**”上過分強調
日誌文件的內容可能會意外傳播。我曾經觀察到在我(外部用戶)打開的票證中,票證系統中兩個支持者之間交換的日誌文件摘要。這些代碼片段是在我遇到問題的時候寫的,但是其中包含許多與其他用戶有關的日誌條目,包括個人身份,明文密碼,明文安全性問題和答案以及用戶之間的關係(是)。有了這些信息,我本可以撥打一個電話號碼,詢問一個特定的名字,然後告訴他們老闆最喜歡的電影是什麼。。。
懷疑論者。SE回答:這都是毫無意義的語法BS。
*“ Twitter和GitHub如何確保它們未被黑客入侵?” *我總是覺得這些問題很有趣。@Kepotx,如何確保您現在不在夢中?
@AndréParamés通過適當使用TPM(例如Qubes的Anti-Evil Maid),可以緩解他們在其中提到的每個問題。
您的問題來自錯誤的前提。即使他們確定自己已經被黑客入侵,也不會公開承認。
因為他們不會透露自己的內部經歷,所以我們只能猜測。但是對於一個假設的場景:假設您將密碼數據洩漏到系統上的日誌文件中,該文件仍然能夠攔截密碼。系統上的任何攻擊者本來都可以在沒有洩漏的情況下對系統進行黑客攻擊,因此洩漏很醜陋,但只要沒有攻擊者,洩漏就不會增加太多危險;如果存在攻擊者,則無論如何他們都具有太多訪問權限。
@MaskedMan-我堅決不同意你的主張。雖然其他一些組織可能會嘗試隱藏已知的黑客行為(*咳嗽* Uber *咳嗽*),但Twitter和Github都非常清楚負責任公開的重要性。您可以肯定他們在這裡是誠實的:是的,他們倆都發現了問題。不,他們不相信任何數據已洩漏;不買,他們不確定,因此您應該更改密碼。最終,幾乎不公開信息總是會咬你(隨著GDPR的生效,實際上任何人都被掩蓋了駭客的攻擊會非常困難)。
@Spudley聽起來您在*同意*我的主張,即使您另有說明。您似乎暗示,只有在被捕獲時,不公開才會咬住它們,並且發生這種情況的可能性很小,或者在被捕獲之前需要花很多時間,那麼就不要透露它們被黑了實際上是一件好事。商業意識。這都是關於風險與回報的關係。
@MaskedMan不,我真的不同意您的意見。風險/報酬論點失敗了,因為風險巨大(GDPR下可能的罰款令人垂涎),並且持續不斷(通過掩蓋駭客行為,您給自己帶來了一個永久性的問題,可以隨時發現該問題)。您也很容易受到任何知道的人的敲詐,這意味著黑客黑了您的壞人現在有了另一種攻擊途徑。任何經過深思熟慮的人都會理解,被黑客入侵後唯一的真實選擇就是全面披露。這可能會很痛苦且令人尷尬,但替代方法卻更糟
-1
所謂的勒索也不用擔心。如果黑客打電話給您說“如果您不付款,我們將向公眾披露該黑客”,您可以要求他們進行威脅。然後,如果他們足夠愚蠢而實際上可以這樣做,則您可以輕鬆地扮演受害者的角色,並聲稱自己在道德上有製高點。換句話說,您可以使用“隱藏技巧”來*提高*您的聲譽。
如果您的系統包含任何歐洲公民的詳細信息,那麼@MaskedMan GDPR *在美國*適用。它的執行力可能較差,但仍然適用。您也沒有掌握這些東西會很快失去控制的螺旋度,以及變得容易。無論如何,從它的聲音來看,我們將不得不同意不同意。我沒有時間繼續爭論這個問題。
@Spudley GPDR與我提出的觀點並沒有真正的關係。不管怎麼說,我是一個黑客,現在他說我在2015年入侵了Facebook。您認為公眾的同情心會在哪裡?另外,另一個有效的技巧是,如果您被方式A駭入,您只想被方式B駭入。這將為您帶來一些布朗尼積分,並且沒人會費心調查其他事情是否還在發生。這與我懷疑Twitter和Github在這裡所做的接近。
您還將使這種hack聲音變得比必要的更具戲劇性。公眾的關注範圍每天都在縮短,在幾個月(甚至幾週)內,沒有人會擔心這種黑客攻擊,他們會安全地躲過雷達。幾年前發現Heartbleed漏洞後,便產生了巨大的歌舞。如果今天有人提出一些其他詳細信息,那麼將有多少人關心?不透露任何不必要的信息在商業上具有完美的意義。由於擔心未來的不確定性和可能性,今天破壞您的業務只是愚蠢的做法。
八 答案:
Anders
2018-05-04 13:18:18 UTC
view on stackexchange narkive permalink

他們不確定。實際上,您永遠無法確定自己沒有被黑客入侵。但是,徹底的檢查可以使您得出結論,可能性更大或更小。

Twitter聲明僅表示沒有跡象表明存在黑客入侵。這並不排除他們被黑客入侵的可能性,並在敦促其用戶更改密碼時,他們暗中承認。

對於GitHub而言,措辭更為明確。但是我認為強制重設密碼表明他們了解所涉及的風險。

“您永遠無法確定自己沒有被黑客入侵”-我不能不同意。
打算開發@PedroLobito嗎?
您可以在氣喘吁籲的機器上構建自己的系統,但是大多數人都不會打擾。
氣喘吁籲的是完全不能保證絕對不會有黑客入侵。除非他的意思是實際上每個組件,例如,一個獨立的電源而不是市電。甚至氣隙都不夠,也許是真空……。但是總會有用戶錯誤,例如我知道例如空氣流通系統本身在停車場植入了USB驅動器,因此遭到了攻擊。還需要考慮的是,由於用戶需要通過身份驗證才能真正使用系統,因此沒有空隙的機器將無用。
您可以確信您還沒有被黑客入侵,最終您將錯了。
任何人都能夠構建系統,而他們*不會入侵。結果是:任何人都可以構建一個無法檢測到黑客入侵的系統。他們正在竭盡所能檢查自己的環境以尋找黑客入侵的證據。他們沒有找到這樣的證據只能證明:*他們*找不到任何證據。由您確定他們的聲明是否滿足您自己的安全性要求。
-1
伊朗的離心機氣隙狹窄。Stuxnet仍然殺死了他們。
好吧,例如,我構建了一個短信設備,該設備使用來自移動電源或牆壁USB適配器的〜100ma@5v,,nodeMCU,通過SPI驅動的,帶有約1“電纜的1.8” LCD,帶有PS2鍵盤作為輸入,HWRNG至生成密鑰,以及可讓相同單元共享密鑰的卡扣連接器。我寫了固件(〜1500 LOC),沒有操作系統。它只知道如何執行所需的操作,並且不允許遠程更新,因此,鑑於此類設備的EMI / RFI很小,而且更改功能所需的實際資產,因此我看不到它是如何容易被黑客入侵甚至洩漏的。不是所有人,而是我的樂趣。
值得深思:如果無法檢測到您被黑客入侵,您是否真的被黑客入侵了?
@ttbek [請注意,研究人員利用噪聲,光和磁鐵來竊取數據](https://www.wired.com/story/air-gap-researcher-mordechai-guri/)。人們也使用室溫來竊取數據,並使用CPU加熱房間。
@drheart您的鏈接無效
Nzall
2018-05-04 14:46:39 UTC
view on stackexchange narkive permalink

還要注意的一件事是,在兩種情況下,洩漏都是在純內部的日誌記錄系統中發生的。沒有跡象表明第三方用戶曾經訪問過該系統。內部日誌記錄系統很少在外部公開,只有在系統需要故障排除時才在內部進行查詢。這也可能是這個錯誤幾個月以來沒有被注意到的原因:單個日誌條目在可能是大量其他語句的某個地方通常不會被注意到,除非它們恰好在需要執行的語句的旁邊或中間。調試其他條目。

Twitter也是最近才發現該錯誤的,這意味著公司外部的人不太可能在Twitter之前就意識到該錯誤,更不用說找出並對其進行攻擊了找回它們。

“很少對外暴露”-是的,只要您記得保護S3存儲設備...
甚至與第三方無關。第一方員工可以很容易地濫用這種東西。
但是,實際上,@djsmiley2k,有多少個主要的信用報告代理機構*實際上*在無擔保的S3存儲桶中存儲了數億個信用文件?
@chrylis顯然,其中大多數。
Tom K.
2018-05-04 16:51:29 UTC
view on stackexchange narkive permalink

很難證明是消極的。

那你如何證明是積極的呢?在這種情況下:您如何證明來自外部的攻擊?通常,有幾個系統可以監視不同形式的攻擊,破壞或訪問。這些可以是防火牆,入侵檢測系統, SIEM以及各種監視和日誌記錄系統。在當今的網絡中,每個組件都具有某種形式的監視,或者允許通過Check_MK等第三方工具進行監視。

因此,從公司網絡邊界到擁有有價值信息本身的機器的每一個步驟都處於某種形式或形式受到監控。這些日誌會根據網絡和公司策略進行定期分析。分析系統可以區分預期的流量和意外的流量或行為。意外/意外行為是實例文件訪問。

內部日誌文件通常被視為機密數據,因此也可能會監視文件訪問。如果不屬於某個用戶組的某人嘗試複製/訪問內部日誌文件,則該日誌很可能被記錄為意外行為,甚至被禁止行為。如果可能的對手能夠冒充訪問該文件的權限,那麼它也會被記錄下來,但是會達到預期的行為。

理論上,攻擊者有可能克服所有安全控制措施,利用0day漏洞,在每個組件,IDS,SIEM等組件的每條日誌中均不留痕跡,將內部日誌文件複製並走私到外部,但這是不太可能的。

我的猜測是,在找到了日誌文件之後,將對所有這些日誌進行全面分析,以嘗試證明是否存在來自外部的攻擊。分析人員沒有發現任何可疑數據,因此得出結論,幾乎絕對可以確定,沒有外界的攻擊。這實際上是您在Twitter的新聞發布中看到的(請參閱Florin Coada的評論)。再說一次,我的猜測是:GitHub的新聞稿使用了更嚴格的語言來阻止人們猜測是否有黑客入侵。 (並沒有真正解決問題。 >

kevin
2018-05-04 15:24:15 UTC
view on stackexchange narkive permalink

我假設他們對服務器上發生的任何事情都有訪問日誌,他們可以檢查是否有人訪問了該文件,訪問的時間,使用的別名,源IP地址等。如果可以證明他們本人認為所有訪問都是由合法員工進行的,他們可以自信地說自己沒有被黑客入侵。請注意,這實際上並不能保證他們不會被黑客入侵,只是所有證據都指向該方向。

MahNas92
2018-05-08 16:28:19 UTC
view on stackexchange narkive permalink

答案很簡單,他們在任何地方都沒有說過肯定的事實,實際上,他們暗中告訴您實際上可能存在兩種違規行為:是“沒有理由相信有”或“沒有證據”違反。缺乏證據可能只是意味著入侵者掩蓋了他們的踪跡。

  • 為了安全起見,他們懇求您更改密碼。這意味著他們不能保證不會發生任何違反行為。
  • ol>
    johannes
    2018-05-04 19:39:01 UTC
    view on stackexchange narkive permalink

    我的解釋,尤其是對更粗體的GitHub語句的解釋是,他們想說密碼已放入日誌文件中的事實不是黑客攻擊的結果,而是開發人員引入調試代碼的結果偶然進入生產。這很重要,因為攻擊者可能已經引入了此功能以便收集密碼以供以後獲取。

    不能保證它們從未被黑客入侵,也永遠不會被黑客入侵,但是此事件是獨立的來自黑客的攻擊。

    user177420
    2018-05-05 15:23:29 UTC
    view on stackexchange narkive permalink

    像這樣的大公司應該有很多服務器,因此所有外部訪問都通過堡壘主機進行路由(外部意味著不在實際的服務器機架/機房內)。堡壘可能會說日誌記錄是以某種方式設置的,因為它會將來自外部網絡的所有命令中繼到操作服務器中。如果記錄了命令,則可以很容易地使用該命令來判斷某人是否以例如vim打開了文件,這將解決用戶是否被黑客入侵的問題。還將記錄SSH訪問,因此可以為用戶過濾出一個已知的“好” IP,並且IT可以檢查任何可疑或奇特的條目,如果無法解釋該條目,則將構成違規。否則,服務器將是“安全的”,並且不必為此事擔心。

    Sentinel
    2018-05-05 22:52:56 UTC
    view on stackexchange narkive permalink

    他們實際上在說的是,他們100%確保確實存在安全漏洞。偶然。大概。和自己。其餘的都是光澤。

    他們可能會以員工的身份對待個人,但我沒有。一個好的黑客從內部進行工作並獲得信任。國家安全局? FSB?

    他們絕不應該以純文本方式訪問我們的密碼。這不是密碼訪問的工作方式。含義是,現在您可以在任何使用過的地方更改該密碼。假設現在每個人都知道密碼。

    如果一個密碼被盜意味著您必須在很多地方進行更改,那是您自己的錯。您不應該首先這樣做。
    @barbecue也正確。此建議適用於主流。到處都可以表示0到很多地方。


    該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
    Loading...