You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.
First of all: sorry for the long wall of text. TL:DR: possible misuse scenario of the Brave Payment system by manipulation of Brave files and / or usage via malware. Technical measures against this seem to me to be possibly non-existent or minimal.
For a different issue I wanted / needed to do an earlier reconciliation of the Brave Payments, and did so by changing the reconcileStamp in ledger-state.json file. This made me think of how somebody could manipulate Brave Payments. As a caveat: until recently I investigated the use of malware, phishing, social engineering and/or any combination thereof aimed at defrauding users.
The possibility of triggering an earlier reconciliation would only be possible by being present on the system and having sufficient rights to change the brave files. This would have to entail the installation of malware on the device. (The misuse by having physical control over somebody's device can happen as well, but this would be misuse on an individual level.)
A criminal would then be able to change the reconciliation moment. In order for this to be profitable they would have to have payments going to sites under their control. This would either mean that they would also have to manipulate other brave history and / or ledger files or manipulate the brave browser to visit their sites. At this moment I am not sure if Brave can be run headless (not visible for the user) and if so, if site visits and usage will then be taken into account for Brave Payments, but that would be a way to do it without manipulating any file whatsoever.
Less careful criminals would try to get as much as possible and will thus try to have the sites under their control to end up with the highest ratio possible. This would either mean a huge influx in visits just before reconciliation or massive pruning / manipulation of ledger and/or history files. It will also be very much visible for users: unknown sites ranking high on their contribution statements.
A more careful criminal would therefor probably try to infect as many users as possible and aim for small amounts from each: a million times $0.05 for a period stretching over many months might slip under the radar and in the end be more profitable than a one time misuse of a million Brave instances at $1 each.
I am not sure how Brave can be defended against this kind of misuse. There is a stop gap measure for the brutal, clumsy and very visible misuse of a big money grab: Brave could choose to always keep the contributions in escrow for a month, making a quick cash out difficult or impossible. The chance of this kind of misuse being discovered within a month could be enough of a deterrent. This however would not work for the more careful siphoning of small amounts over longer periods.
Another measure might be to not have headless operations contribute to Brave Payments (if that is now the case and / or even possible).
I cannot think of a workable measure against the manipulation of files. In theory this could be done with checksums, but the overhead would be killing.
Even though this kind of misuse is hypothetical at the moment, the chance of people looking into possibilities to manipulate the Brave Payment system will grow with the number of Brave users.
Anybody have any idea on how to defend against this, or have more insight into the likelihood of such misuse scenarios happening, or insight in other possible ways to defraud the system and / or user?
The text was updated successfully, but these errors were encountered:
Thanks for opening a detailed issue. I think we can agree that it's out-of-scope for the ledger to defend against every possible type of malware and social engineering, so I'll focus on specific scenarios:
Malware that can write to the ledger state files, overriding the reconcileStamp, but cannot run arbitrary code (such as running a headless browser and spoofing browser UI actions): This can be mitigated by requiring the user to click through an approval prompt before money is transferred, which shows them the reconcileStamp. Alternatively, if the ledger state files are encrypted on-disk, this wouldn't be an issue.
Malware that can read ledger state files: I'm pretty sure they can just steal the BTC wallet in this case. Can also be mitigated by encrypting ledger files on-disk.
Malware that can run arbitrary code: The user has a lot of ways they can lose money (ransomware, stealing bank passwords, etc.), which is probably out-of-scope for Brave to defend against.
The simplest solution against (1) and (2) is encrypting ledger files using a keychain-stored password, but that comes with some inconveniences like forcing Brave Payments users to allow keychain access to Brave, losing all payments data if the keychain password is lost/deleted, and making debugging harder.
First of all: sorry for the long wall of text. TL:DR: possible misuse scenario of the Brave Payment system by manipulation of Brave files and / or usage via malware. Technical measures against this seem to me to be possibly non-existent or minimal.
For a different issue I wanted / needed to do an earlier reconciliation of the Brave Payments, and did so by changing the reconcileStamp in ledger-state.json file. This made me think of how somebody could manipulate Brave Payments. As a caveat: until recently I investigated the use of malware, phishing, social engineering and/or any combination thereof aimed at defrauding users.
The possibility of triggering an earlier reconciliation would only be possible by being present on the system and having sufficient rights to change the brave files. This would have to entail the installation of malware on the device. (The misuse by having physical control over somebody's device can happen as well, but this would be misuse on an individual level.)
A criminal would then be able to change the reconciliation moment. In order for this to be profitable they would have to have payments going to sites under their control. This would either mean that they would also have to manipulate other brave history and / or ledger files or manipulate the brave browser to visit their sites. At this moment I am not sure if Brave can be run headless (not visible for the user) and if so, if site visits and usage will then be taken into account for Brave Payments, but that would be a way to do it without manipulating any file whatsoever.
Less careful criminals would try to get as much as possible and will thus try to have the sites under their control to end up with the highest ratio possible. This would either mean a huge influx in visits just before reconciliation or massive pruning / manipulation of ledger and/or history files. It will also be very much visible for users: unknown sites ranking high on their contribution statements.
A more careful criminal would therefor probably try to infect as many users as possible and aim for small amounts from each: a million times $0.05 for a period stretching over many months might slip under the radar and in the end be more profitable than a one time misuse of a million Brave instances at $1 each.
I am not sure how Brave can be defended against this kind of misuse. There is a stop gap measure for the brutal, clumsy and very visible misuse of a big money grab: Brave could choose to always keep the contributions in escrow for a month, making a quick cash out difficult or impossible. The chance of this kind of misuse being discovered within a month could be enough of a deterrent. This however would not work for the more careful siphoning of small amounts over longer periods.
Another measure might be to not have headless operations contribute to Brave Payments (if that is now the case and / or even possible).
I cannot think of a workable measure against the manipulation of files. In theory this could be done with checksums, but the overhead would be killing.
Even though this kind of misuse is hypothetical at the moment, the chance of people looking into possibilities to manipulate the Brave Payment system will grow with the number of Brave users.
Anybody have any idea on how to defend against this, or have more insight into the likelihood of such misuse scenarios happening, or insight in other possible ways to defraud the system and / or user?
The text was updated successfully, but these errors were encountered: