成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Signal修復了一個允許攻擊者破壞加密附件的bug

譯文
安全
Signal應用可謂是最可信的消息傳遞應用程序,但它并不完美的。

[[172485]]

【51CTO.com快譯】導言:Signal應用可謂是最可信的消息傳遞應用程序,但它并不完美的。

Signal應用,一款由美國國家安全局(NSA)泄密者--愛德華·斯諾登和大量的安全專家推薦的移動消息傳送應用,近期修復了一個允許攻擊者將隨機數添加到由Android用戶發送的加密消息附件里的錯誤(bug)。該更新已在Github(面向開源及私有軟件項目的托管平臺)的項目子集里可獲取到,但在谷歌的Android應用市場—Google Play里尚無。

旁路消息驗證(message authentication-bypass)的脆弱性是由研究人員Jean-Philippe Aumasson和Markus Vervier在一次非正式的檢查Android版本的Signal所使用的Java代碼時發現出的多個弱點中的一個。該bug將使得那些破壞或假冒Signal服務器的攻擊者有可能通過添加隨機數據來修改“合法”的附件。第二個bug則可能是允許攻擊者遠程執行惡意代碼;而Vervier先生告訴本刊記者,第三個bug是一個簡單的遠程導致系統崩潰手段的有限利用。

“雖然結果并非不是災難性,但這表明,和其他的軟件一樣,Signal應用也并非完美。”Aumasson先生在一封郵件中這么寫道,“Signal應用吸引了許多安全研究人員的注意。在此之前,其‘無脆弱性’曾給大家留下了深刻印象。但該發現是有益于Signal應用的,我們仍將繼續信任它。”

附件破壞的脆弱性來自整數類型數據溢出的bug,即:當有非常大的文件集(至少4 GB大小)被附加到消息里時就會被觸發。Signal應用將會檢查一小部分,而并非驗證整體文件真實性這一特點,使得攻擊者可以添加偽隨機數據而不會被MAC(消息驗證碼)所檢測到,盡管MAC已是大多數加密方案里的一個標準部分。為了使得此攻擊更具操作性,攻擊者可以使用Signal應用所支持的文件壓縮來將惡意附件的大小減少到可控的4MB以用于運輸。

在郵件中,Aumasson聲稱數據溢出的bug可在如下代碼行中被發現:

  1. int remainingData = (int) file.length() - mac.getMacLength(); 

他的解釋是:此處“file.length()”的值是一個64位編碼的數值(“長整型”),而接收變量--“remainingData”卻是一個32位 (“int,整型”)。因此,當“file.length()”比適合32位的數值還要長的時候,“remainingData”(剩下用于處理的字節數)的值將不正確,因為它將比實際文件的大小要小得多。因此,當Signal應用驗證加密的真實性的時候,文件的很大部分將被忽略掉了。Signal應用只會檢查文件的開始一小部分,而用戶卻實際上將接收的是更大的文件。

Signal應用吸引人的原因之一就是它部署的是端到端加密,也就意味著它在發送方的設備上加密一條消息,直到安全地存儲到了接收設備上才進行解密。當然,加密的消息要經過一個服務器。那么黑客就可以冒充該服務器,繞過消息身份驗證,進而篡改信息附件。為了繞過傳輸層的安全保護,攻擊者可能需要黑掉Android操作系統所信任的數以百計的權威證書簽發機構中的某一個或誘騙其目標在設備上安裝一個假的CA證書。下面是更細節化的漏洞分析:

為了防止被第三方(也包括Signal的維護人員)所閱讀或改變,Signal應用的附件是被加密驗證的。相對于“消息驗證再加密”(如TLS)和“加密并消息驗證”(如SSH)的做法,Signal則使用的是“加密再消息驗證”,這一最為安全的方法。

如果消息和附件被發送,其附件被單獨下載到AWS服務器上,如https://whispersystems-textsecure-attachments.s3.amazonaws.com/。附件被發送方用PKCS7的AES-128-CBC進行加密,以及HMAC-SHA-256進行認證,而且使用的是128位密鑰。

通過HTTPS方式下載的附件被保存到Android存儲空間。Signal的服務對文件的MAC使用如下代碼進行檢查。其文件路徑是:

  1. :libsignal-service-java/java/src/main/java/org/whispersystems/signalservice/api/crypto/AttachmentCipherInputStream.java: 
  2.   private void verifyMac(File file, Mac mac) throws FileNotFoundException, InvalidMacException { 
  3.     try { 
  4.       FileInputStream fin           = new FileInputStream(file); 
  5.       int             remainingData = (int) file.length() - mac.getMacLength(); 
  6.       byte[]          buffer        = new byte[4096]; 
  7.  
  8.       while (remainingData > 0) { 
  9.         int read = fin.read(buffer, 0, Math.min(buffer.length, remainingData)); 
  10.         mac.update(buffer, 0, read); 
  11.         remainingData -read
  12.       } 
  13.  
  14.       byte[] ourMac   = mac.doFinal(); 
  15.       byte[] theirMac = new byte[mac.getMacLength()]; 
  16.       Util.readFully(fin, theirMac); 
  17.  
  18.       if (!Arrays.equals(ourMac, theirMac)) { 
  19.         throw new InvalidMacException("MAC doesn't match!"); 
  20.       } 
  21.     } catch (IOException e1) { 
  22.       throw new InvalidMacException(e1); 
  23.     } 
  24.   } 

如上所述remainingData的類型是int(整形),由文件的長度減去MAC的長度得出。因為file.length()將返回一個長整型值而文件可能大于Integer.MAX_VALUE,所以remainingData將被略過了。

不像C(+ +)語言,Java是“記憶安全”的,也就不會導致任何經典的內存崩潰狀態。然而,我們卻可以使用此溢出來破壞程序的邏輯。現在,如果文件大小是4BG + 1byte+ X,其價值將被略過,remainingData也將被設置為X。

不巧的是:Signal應用將所有附件存儲在AWS S3上,以HTTPS的方式獲取它們,并使用系統證書集來檢查服務器的證書(注意:在S3服務器上的Signal用的是通配符:*.s3.amazonaws.com)。因此具有訪問Amazon S3權限或具有其他Android系統所信任的CA證書的實體,可以用下列步驟修改附件:

1.等待取附件的請求。

2.取出原始附件的大小X。

3.用4GB + 1byte的數據來填充附件,以得到X + 4GB + 1的總共大小。

如上所述,這將導致X字節通過verifyMAC()的檢查,而原始的MAC已然合法。因此,我們可以將任意數據添加到文件,而MAC的檢查是不會報錯的!

值得注意的是:攻擊者并不需要在任何網絡連接中真實發送超過4GB的數據,如果我們使用gzip進行HTTP的流壓縮,我們就能創建一個4GB的文件而實際壓縮下來卻只有4.5MB。如下所示:

  1. [s@polo tools-markus]$ python2 sap.py --encoding gzip 
  2. Serving HTTP on 0.0.0.0 port 8000 ... 
  3. opening: https://whispersystems-textsecure-attachments.s3.amazonaws.com/attachments/id1/id2... 
  4. * Compressing content... 
  5. ** Padding content... 
  6. ** Finished 
  7. Compressed Content Length (Raw 49284): 4458483 
  8. * Set Content-Length to: 4458483 
  9. * Sent header, writing content 
  10. * Request finished 

通過查看Android的調試日志,我們現在看到如下異常代碼:

  1. W/AttachmentDownloadJob(10484): ws.com.google.android.mms.MmsException: java.io.IOException: javax.crypto.BadPaddingException: EVP_CipherFinal_ex 
  2. W/AttachmentDownloadJob(10484):         at org.thoughtcrime.securesms.database.AttachmentDatabase.setAttachmentData(AttachmentDatabase.java:427) 
  3. W/AttachmentDownloadJob(10484):         at org.thoughtcrime.securesms.database.AttachmentDatabase.setAttachmentData(AttachmentDatabase.java:412) 
  4. W/AttachmentDownloadJob(10484):         at org.thoughtcrime.securesms.database.AttachmentDatabase.insertAttachmentsForPlaceholder(AttachmentDatabase.java:255) 
  5. W/AttachmentDownloadJob(10484):         at org.thoughtcrime.securesms.jobs.AttachmentDownloadJob.retrieveAttachment(AttachmentDownloadJob.java:120) 
  6. W/AttachmentDownloadJob(10484):         at org.thoughtcrime.securesms.jobs.AttachmentDownloadJob.onRun(AttachmentDownloadJob.java:84) 
  7. W/AttachmentDownloadJob(10484):         at org.thoughtcrime.securesms.jobs.MasterSecretJob.onRun(MasterSecretJob.java:18) 
  8. W/AttachmentDownloadJob(10484):         at org.whispersystems.jobqueue.JobConsumer.runJob(JobConsumer.java:76) 
  9. W/AttachmentDownloadJob(10484):         at org.whispersystems.jobqueue.JobConsumer.run(JobConsumer.java:46) 
  10. W/AttachmentDownloadJob(10484): Caused by: java.io.IOException: javax.crypto.BadPaddingException: EVP_CipherFinal_ex 
  11. W/AttachmentDownloadJob(10484):         at org.whispersystems.signalservice.api.crypto.AttachmentCipherInputStream.readFinal(AttachmentCipherInputStream.java:129) 
  12. W/AttachmentDownloadJob(10484):         at org.whispersystems.signalservice.api.crypto.AttachmentCipherInputStream.read(AttachmentCipherInputStream.java:100) 
  13. W/AttachmentDownloadJob(10484):         at org.whispersystems.signalservice.api.crypto.AttachmentCipherInputStream.read(AttachmentCipherInputStream.java:94) 
  14. W/AttachmentDownloadJob(10484):         at org.thoughtcrime.securesms.util.Util.copy(Util.java:220) 
  15. W/AttachmentDownloadJob(10484):         at org.thoughtcrime.securesms.database.AttachmentDatabase.setAttachmentData(AttachmentDatabase.java:425) 
  16. W/AttachmentDownloadJob(10484):         ... 7 more 
  17. W/AttachmentDownloadJob(10484): Caused by: javax.crypto.BadPaddingException: EVP_CipherFinal_ex 
  18. W/AttachmentDownloadJob(10484):         at com.android.org.conscrypt.NativeCrypto.EVP_CipherFinal_ex(Native Method) 
  19. W/AttachmentDownloadJob(10484):         at com.android.org.conscrypt.OpenSSLCipher.doFinalInternal(OpenSSLCipher.java:430) 
  20. W/AttachmentDownloadJob(10484):         at com.android.org.conscrypt.OpenSSLCipher.engineDoFinal(OpenSSLCipher.java:490) 
  21. W/AttachmentDownloadJob(10484):         at javax.crypto.Cipher.doFinal(Cipher.java:1314) 
  22. W/AttachmentDownloadJob(10484):         at org.whispersystems.signalservice.api.crypto.AttachmentCipherInputStream.readFinal(AttachmentCipherInputStream.java:124) 
  23. W/AttachmentDownloadJob(10484):         ... 11 more 

檢查MAC后,類構造函數--AttachmentCipherInputStream將創建一個javax.crypto.Cipher類的實例:

  1. public AttachmentCipherInputStream(File file, byte[] combinedKeyMaterial) 
  2.       throws IOException, InvalidMessageException 
  3.   { 
  4. ... 
  5.       verifyMac(file, mac); 
  6.  
  7.       byte[] iv = new byte[BLOCK_SIZE]; 
  8.       readFully(iv); 
  9.  
  10.       this.cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); 
  11.       this.cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(parts[0], "AES"), new IvParameterSpec(iv)); 
  12.  
  13.       this.done          = false
  14.       this.totalRead     = 0
  15.       this.totalDataSize = file.length() - cipher.getBlockSize() - mac.getMacLength(); 
  16.     } catch (NoSuchAlgorithmException | InvalidKeyException | NoSuchPaddingException | InvalidAlgorithmParameterException e) { 
  17.       throw new AssertionError(e); 
  18.     } catch (InvalidMacException e) { 
  19.       throw new InvalidMessageException(e); 

達到這種狀態時,我們便可以對自己所選取的密碼進行解密了。

研究人員已將此漏洞在9月13日“私信”了Signal應用的開發商Open Whisper Systems公司,該司也已發布了相應的更新。Kudelski安全公司的首席研究員Aumasson先生和X41公司的首席執行官兼安全研究主任Vervier先生分別聲稱他們仍在研究這次bug是否也影響到了依賴于Signal代碼的WhatsApp和Facebook消息傳遞應用。

在郵件中,Open Whisper Systems公司的創辦人Moxie Marlinspike寫到:這是一個重大的錯誤報告,但我們認為當前其影響程度仍較低。它并不允許攻破了服務器的黑客去讀取或修改附件,而只能添加一個最低為4GB的不可預測的隨機數據到附件尾部用于傳輸。在有效地以不可預知的方式破壞文件并使之太大,從而無法在Android設備上打開的同時,入侵了服務器的黑客就很容易通過拒絕你的附件要求的方式使服務器不再提供服務。

參考原文:

http://arstechnica.com/security/2016/09/signal-fixes-bug-that-let-attackers-tamper-with-encrypted-messages/

https://pwnaccelerator.github.io/2016/signal-part1.html

【51CTO譯稿,合作站點轉載請注明原文譯者和出處為51CTO.com】

責任編輯:趙寧寧 來源: 51CTO.com
相關推薦

2022-07-21 18:02:38

思科漏洞攻擊者

2021-04-22 09:33:37

Azure漏洞攻擊

2021-03-15 13:56:00

DDoS攻擊加密貨幣

2022-05-16 08:42:26

Pandasbug

2021-11-04 05:48:43

SSL加密攻擊勒索軟件

2022-02-16 11:51:16

McAfee漏洞Windows

2024-10-18 17:10:45

2014-08-20 09:44:57

2018-06-13 08:01:54

2023-05-15 15:59:07

2022-04-28 21:42:38

漏洞勒索軟件網絡攻擊

2023-02-17 18:30:50

2010-09-25 15:40:54

2024-12-19 15:13:26

2024-12-31 15:49:54

2021-09-03 14:59:10

Linux漏洞攻擊

2014-12-17 09:40:22

dockerLinuxPaaS

2015-10-12 10:13:52

2022-08-19 15:40:08

密碼證書安全

2021-06-07 09:41:29

AWSVPC虛擬網絡服務
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 中文字幕亚洲一区二区va在线 | 色黄爽 | 亚洲国产中文字幕 | 亚洲欧美日韩精品久久亚洲区 | 超碰97人人人人人蜜桃 | 日日夜夜av| 国产综合久久 | 国产日韩精品在线 | 国产亚洲精品久久久久久牛牛 | 国产99久久精品一区二区永久免费 | 亚洲经典一区 | 日韩久久久一区二区 | 国产在视频一区二区三区吞精 | av国产精品 | 国产在线对白 | 国产精品毛片在线 | 超黄毛片 | 欧美视频二区 | 国产精品视频一区二区三区 | 国产精品一区二区三区久久久 | 视频一区二区在线观看 | 成人综合一区二区 | 91看片在线 | 国产精品高潮呻吟久久aⅴ码 | 酒色成人网 | 黑人精品欧美一区二区蜜桃 | 婷婷五月色综合 | 精品国产一区二区三区av片 | 污视频在线免费观看 | 日韩视频在线观看中文字幕 | 日本午夜一区二区三区 | 99久久影院 | 国产欧美综合在线 | 久久国产免费 | 三级在线视频 | 超碰国产在线 | 午夜视频网站 | 亚洲精品久 | 天天躁人人躁人人躁狂躁 | 黄色网址免费看 | 国产成人jvid在线播放 |