search

tari-project / universe

Other
8 stars 24 forks source link

User Experience - Updates have different sha values and EDR (AV) are constantly having to be allow-listed /* v0.4.x -> v0.5.x #627

Open uforiaio opened 1 month ago

uforiaio commented 1 month ago

Describe the bug

Updates to the mining software frequently have different SHA values, triggering alerts from Endpoint Detection and Response (EDR) systems or Antivirus (AV) programs. This causes legitimate miners to be flagged as potential threats, requiring constant allow-listing of the application. Given that malware often uses mining software for malicious purposes, users—especially those new to mining—may have difficulty understanding the issue and may be unsure how to correctly add exceptions to their EDR/AV software. This makes legitimate mining setups more challenging and problematic for inexperienced users. This has happened in three or four of the updates, but not on all EDR packages. It is not consistent, but even with adding an exception for a folder, it will still trigger a block. From what I recall, there were thirty-three means of priv escalation in Windows if you use the MITRE ATTACK/DEFEND frameworks, but it may be fewer or more, the count is fluid based on Microsoft's patching efforts.

To Reproduce Steps to reproduce the behavior

Users should be able to update the mining software without constantly needing to allow-list it in their EDR/AV software. A more seamless experience could be achieved if the software were code-signed (the binaries are signed..), or at a minimum, better explained to the users in the README. The README should clarify the legitimate use of the mining software and explain why these security flags occur and how to handle them safely.

Screenshots

image

Log Example

C:\Users\$username\AppData\Local\com.tari.universe\binaries\tari\nextnet\1.5.1-rc.3\minotari_node.exe [SHA256: 481422BE95966F2C7232C3CB543BB8995658C0646B7889742426F268A610269C] [MD5: 533559E01A555BEBBCA8C551501E7783] [Flags: 10091011.25850]

Desktop

OS & Version: Windows 11 Version 23H2 (OS Build 22631.4169) GPUs: Nvidia RTX 4090 (on affected systems), AMD 7900 XTX (issue was reproduced intentionally) GPU Drivers: Nvidia and AMD (Tried newest drivers, as well as two older drivers) Browser & Version: All browsers since they use GPU Smartphone: n/a AV/EDR/XDR: Webroot, BitDefender, ESET, and Avast One have the issue.

Notes

Miners are often used in malware attacks, which leads to legitimate mining binaries being flagged as threats by EDR/AV systems. Code signing could be a potential solution to reduce false positives, though it may not be feasible in all cases. At a minimum, the README should clearly explain how to add exceptions for the software, while acknowledging the reality that bad actors also use these binaries for malicious purposes. Clear instructions will help users differentiate between legitimate use and potential security threats. This would improve user trust and overall experience.

uforiaio commented 1 month ago

I validated in my three edr logs that the sha values changing will be problematic. Code signing may help, but with the high usage of monero by bad actors, this is a tough one.

uforiaio commented 1 month ago

Also, on updates the kill script is not working all the time. I am guessing that you the script is doing a tasklist | findstr "tari universe.exe" programmatically, and is not finding both PID's. On two of my three machines running right now, one of the PID's appears to have been missed or file locked.

minotari_node.exe 102772 RDP-Tcp#0 2 326,264 K minotari_console_wallet.e 168084 RDP-Tcp#0 2 68,280 K minotari_merge_mining_pro 170580 RDP-Tcp#0 2 22,680 K

image

uforiaio commented 1 month ago

With the client closed, there are ghost pid's

image

uforiaio commented 1 month ago

I would validate that the cmd/ps process is being launched as an admin. There are some security concerns, but with the way Universe appears to work

Running cmd.exe as normal user:

image

Launching cmd.exe as an admin:

image

uforiaio commented 1 month ago

Thought it could be a code-signing issue, it was not. Looking elsewhere.

Taking a different approach since the parent binary validates.

signtool.exe verify /pa /v "C:\Program Files\Tari Universe\Tari Universe.exe"

Verifying: C:\Program Files\Tari Universe\Tari Universe.exe

Signature Index: 0 (Primary Signature) Hash of file (sha256): 6404BDBAD40CD9642D1FDF7EBE8D6B6CDF3FA8074A02EBEE90426F2317C48BEC

Signing Certificate Chain: Issued to: Microsoft Identity Verification Root Certificate Authority 2020 Issued by: Microsoft Identity Verification Root Certificate Authority 2020 Expires: Sun Apr 16 13:44:40 2045 SHA1 hash: F40042E2E5F7E8EF8189FED15519AECE42C3BFA2

    Issued to: Microsoft ID Verified Code Signing PCA 2021
    Issued by: Microsoft Identity Verification Root Certificate Authority 2020
    Expires:   Tue Apr 01 15:15:20 2036
    SHA1 hash: 8E750F459DAF9A79D6370DB747AD2226866AD818

        Issued to: Microsoft ID Verified CS AOC CA 01
        Issued by: Microsoft ID Verified Code Signing PCA 2021
        Expires:   Mon Apr 13 12:31:54 2026
        SHA1 hash: D7B1118AFBB879D9F2F8E98B9AC12F9367FACE88

            Issued to: Tari Labs LLC
            Issued by: Microsoft ID Verified CS AOC CA 01
            Expires:   Fri Sep 27 22:54:46 2024
            SHA1 hash: 70F06448FF7FAB945B003D0376E83233E8BED537

The signature is timestamped: Wed Sep 25 11:59:20 2024 Timestamp Verified by: Issued to: Microsoft Identity Verification Root Certificate Authority 2020 Issued by: Microsoft Identity Verification Root Certificate Authority 2020 Expires: Sun Apr 16 13:44:40 2045 SHA1 hash: F40042E2E5F7E8EF8189FED15519AECE42C3BFA2

    Issued to: Microsoft Public RSA Timestamping CA 2020
    Issued by: Microsoft Identity Verification Root Certificate Authority 2020
    Expires:   Mon Nov 19 15:42:31 2035
    SHA1 hash: 27F0ABAC2877BA255F62B389B43FF539A0FB598E

        Issued to: Microsoft Public RSA Time Stamping Authority
        Issued by: Microsoft Public RSA Timestamping CA 2020
        Expires:   Sat Feb 15 15:35:52 2025
        SHA1 hash: 2FECBB8692081AB7B596E88AA3A0E71700CB62D9

Successfully verified: C:\Program Files\Tari Universe\Tari Universe.exe

Number of files successfully Verified: 1 Number of warnings: 0 Number of errors: 0

——————-

Also checked most of the binaries.

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64\signtool.exe" verify /pa /v "C:\Users\kvizena\AppData\Local\com.tari.universe\binaries\tari\nextnet\1.5.1-rc.3*.exe"

Number of files successfully Verified: 4 Number of warnings: 0 Number of errors: 0

uforiaio commented 1 month ago

One vendor is triggering off of the name or the sha that has been flagged:

image

More mainline vendors are noticing the code signing, and not flagging it:

image

uforiaio commented 1 month ago

With ML executing the code in an explosion chamber, then looking at the actions this will be a hard one to fix.

I would use VirusTotal API v3 to check my binaries to see if they are flagged.

uforiaio commented 1 month ago

The binaries are code signed, and some edr/xdr vendors will use threat scores, even when AV is clean. The only solution I can think of is to document the issue well in the readme.md or in the client docs. Obfuscating code, renaming the files, or modifying the sha values will not have much success since most ai/ml to execute the binaries to see if they exhibit any of the potentials for priv escalation.

image

https://www.hybrid-analysis.com/sample/481422be95966f2c7232c3cb543bb8995658c0646b7889742426f268a610269c/66f567085541d5d3bd0d0741