Penetration Test Report (Cure53): pentest report frame

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report Frame Electron App 08.2018
Cure53, Dr.-Ing. M. Heiderich, BSc. T.-C. “Filedescriptor” Hong, M. Kinugawa, MSc. N. Kobeissi
Index
Introduction
Scope
Identified Vulnerabilities
FRM-01-001 Frame: Origin-spoofing due to unwrapped overflowing text (Low)
FRM-01-004 Frame: Denial of Service via undefined commands (Low)
Miscellaneous Issues
FRM-01-002 Frame: Bait and Switch attack on approving Dapps (Info)
FRM-01-003 Frame: Bypassable CSP rules in place (Info)
FRM-01-005 Frame: nodeIntegration enabled in renderer (Info)
FRM-01-006 Frame: Missing contextIsolation mitigation (Info)
Conclusions
Introduction
“Frame is an OS-level Ethereum interface that lets you use standalone signers, such as
a Ledger or Trezor, to interact with dapps and the Ethereum network”
From https://frame.sh/
This report documents the findings of a security assessment targeting the Frame
desktop application. The project was carried out by Cure53 in 2018 and yielded six
security-relevant issues, mostly characterized by rather limited impact.
It needs to be noted that the assessment comprised both a penetration test and a source
code audit against the Frame project in scope. In terms of the resources, Cure53
created a team of four testers who were allocated with a time budget of six days for the
completion of this project. In line with the schedule, the tests and auditing took place in
late August and early September of 2018. Given that Frame is open sourced and as
such publicly available, the methodology employed by Cure53 was a white-box
approach. This means that the testers had access to all relevant information.
The testing efforts concentrated on several focal areas of the Frame desktop application.
Specifically, Cure53 zoomed in on the locally spawned servers, the cryptographic
implementation, as well as the Electron security settings more generally. It needs to be
noted that the testers have reached a complete coverage on the agreed scope.
Under the white-box premise, the communications with Jordan Muir, who is the
maintainer of the Frame software, were done via Gitter. This has proven to be a very
productive method since the team managed to live-report issues and discuss the fixes
Cure53, Berlin · 09/06/18 1/8
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
as well. In fact, some of the mitigations were not only deployed but also verified by
Cure53 as the tests were still ongoing. All in all, the project has been noted as very
effective, efficient and fruitful.
In the following sections, the report first sheds light on the scope and the resources
shared with the Cure53 team for the purpose of this project. After that, the discussions
move on to the spotted findings, which are addressed both from a technical standpoint,
and in terms of forward-looking advice on mitigation. Lastly, the report will close with a
conclusion, which offers some broader impressions that the Cure53 testers have gained
from auditing the Frame application.
Scope
• Frame Electron App
◦ https://github.com/floating/frame/tree/master
◦ https://github.com/floating/frame/releases
• Frame Libraries
◦ https://github.com/floating/eth-provider/tree/master
◦ https://github.com/floating/restore/tree/master
• Pre-Builds
◦ https://frame.nyc3.digitaloceanspaces.com/0.0.6/Frame-0.0.6.dmg
◦ https://frame.nyc3.digitaloceanspaces.com/0.0.6/Frame_0.0.6_amd64.deb
◦ https://frame.nyc3.digitaloceanspaces.com/0.0.6/Frame_0.0.6_amd64.snap
◦ https://frame.nyc3.digitaloceanspaces.com/0.0.6/Frame-0.0.6-x86_64.AppImage
◦ https://frame.nyc3.digitaloceanspaces.com/0.0.6/Frame-0.0.6.tar.gz
◦ https://frame.nyc3.digitaloceanspaces.com/0.0.6/Frame-Setup-0.0.6.exe
Cure53, Berlin · 09/06/18 2/8
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact. The aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. FRM-01-001) for the purpose of facilitating any
future follow-up correspondence.
FRM-01-001 Frame: Origin-spoofing due to unwrapped overflowing text (Low)
It was found that a long origin can overflow the Frame’s content box. More specifically,
an origin overflows when its host-name contains consecutive special characters.
Normally, browsers refuse to navigate to a domain with special characters. In Safari,
however, special characters are accepted by subdomains. Therefore, it is possible to set
up a crafted subdomain (e.g. http://frame.sh___.evil.com) to perform a visual spoofing
attack. In this scenario, the special characters overflow so that the “real domain” is
pushed to an invisible area.
Steps to Reproduce:
• With Safari, navigate to
http://frame.sh ___________________________________ .216.58.200.14.nip.io
• Open the DevTool’s console.
• Execute the following code:
new WebSocket('ws://127.0.0.1:1248')
• The request dialog will show that frame.sh is requesting approval despite it not
actually coming from frame.sh.
In addition, it was discovered that such a long origin prevents revoking access since the
toggle button is also pushed to an invisible area.
Cure53, Berlin · 09/06/18 3/8
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Fig.: Long origin overflowing content box and resulting in spoofing
It is recommended to break the long text, thus preventing overflow. It is further advised
for the origin domain with invalid syntax to be filtered.
FRM-01-004 Frame: Denial of Service via undefined commands (Low)
It was discovered that the Frame desktop application’s local server does not return
responses correctly when an undefined command is sent. Due to this behavior, the
application can be disabled from any permitted Dapp-origin by sending a malformed
request.
Steps to Reproduce:
• Set the https://frame.sh origin as the permitted origin.
• Navigate to https://frame.sh/
• Open the DevTools’ console.
• Execute the following code:
fetch("http://127.0.0.1:1248/",
{"method":"post","body":'{"jsonrpc":"2.0","id":1,"method":"aaa","params":
[]}'})
Cure53, Berlin · 09/06/18 4/8
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
• Click on the “SEND A RINKEBY TEST TRANSACTION” button. The command
will no longer work until a user restarts the Frame application
The security impact of this flaw is limited since only the permitted Dapp-origins can send
the request causing a DoS. What is more, the application can be recovered with a
simple restart. It is nevertheless recommended to ensure that any undefined commands
are handled properly.
Miscellaneous Issues
This section covers those noteworthy findings that did not lead to an exploit but might aid
an attacker in achieving their malicious goals in the future. Most of these results are
vulnerable code snippets that did not provide an easy way to be called. Conclusively,
while a vulnerability is present, an exploit might not always be possible.
FRM-01-002 Frame: Bait and Switch attack on approving Dapps (Info)
It was found that when there are two Dapps requesting permission at the same time, the
latecomer will have its request dialog stacked on top. This allows an attacker to first
present a legitimate request from a trusted origin. Then, with an immediate action when
a user is about to click on the “approve” button, the attacker quickly sends another
request from a malicious origin. As a result, the user eventually approves the malicious
Dapps.
Steps to Reproduce:
• Ensure Frame is running and a hardware wallet is in an unlocked state.
• Navigate to any website (e.