Internet banking in Brazil and Warsaw (the software)
13-07-2024
What is it?
Warsaw, currently developed by Topaz-Stefanini (and curiously enough, in some tutorials referenced as a product of GAS Technologies, a subsidiary of Diebold), is an opaque bit of software "which provides active protection against cyber threats on your personal computer.". Described as an anti-malware, anti-phishing tool with dubious credentials, it is a constant nuisance and prevents me from doing internet banking.
Officially, my bank only provides support for Debian-based distributions (more specifically, Ubuntu 18, 17, 16), although there are RPM packages available as well.
Why is it bad?
The core module for Warsaw is often reported to be a resource hog on Windows, taking up to 40% of CPU time for itself in some reports. It also conflicts with anti-cheat technologies and anti-malware software, preventing games from being launched and constant firewall triggers.
Funnily enough, it is so intrusive, the official stance for some technical support providers is to uninstall the application altogether, as it negatively impacts the stability of... structural analysis software, for example.
It's also not free from vulnerabilities itself, with the most recent being CVE-2023-5012, relating to untrusted search paths. Removing it in full is also not trivial, as it is known to leave behind unaccounted for files and lasting unexpected behaviour.
Notwithstanding the previous concerns, it explicitly states that it collects uniquely identifiable user information, triggering judicial action.
Setup
All the information was collected on a fresh install of Debian 12, running with QEMU. Only basic system utilities, Wireshark, GCC build essentials and Firefox were installed. Warsaw did require Zenity as a dependency, so that was installed as well.
There is no indication that these results also apply to the Windows version of Warsaw, as that one may receive significant more developer attention.
What information does it collect?
Hard to say, as traffic is encrypted and I have no access to keys of any sort. Traffic when accessing bank pages is as expected, with plenty of it coming and going to *.dnofd.com, which belongs to Topaz software. After 30 minutes idle, some packets are sent to bb.dnofd.com, which is Banco do Brasil's special data endpoint, and global.dnofd.com, the contents of which are also encrypted.
Packets can be as large as 1.3kB (received from global.dnofd.com), but on average, they were comprised of less than 500 bytes of data. This possibly indicates that no detailed keylogging information is sent, at least whilst the computer is idle. It is entirely possible more detailed data is sent during banking activity.
On startup, no data is sent for 10 minutes, until a packet is received from global.dnofd.com, and a short response follows from the local client.
Resource usage
Resource usage whilst accessing bank pages is intense and resulted in a slowdown of my QEMU VM, peaking at 50% for extended periods of time whilst the page was being interacted with (login, data entry, etc). When "idle", the application has periodic peaks of 8% usage, which doesn't result in major noticeable slowdowns, but it does have a negative performance effect:
These longer peaks are not necessarily network activity; only one of them lines up with the delayed idle phone home.
It exhibits the same behaviour on startup.
On Linux, the processes (2) are spawned with a default nice of 0, and running as root, as it installs a fairly trivial service pointing to the core binary.
Conclusion
Fair to say there isn't a smoking gun to point at. Although all that phoning home doesn't leave me at ease, the contents are still unknown, and it could be mostly benign for all we know.
Resource wise, it is indeed a resource hog, and the 8% peaks could negatively affect other applications running simultaneously, with users providing anecdotal evidence to that. As for memory use, it remained fairly stable at 48MB non-shared physical memory for the main process.
There's also the possibility I didn't trigger any specific heuristics in its "protection" routine that would cause larger CPU spikes, or additional network activity, which I am probably going to attempt in the future with known phishing addresses.
It is an anticlimatic end to this post to say that no conclusive evidence for anything was found, but I plan to disassemble the binary and rumage through my findings to see if anything suspicious can be found, but I hold no promises.