Actions

Malware and Firmware Trojans

From Whonix

(Redirected from Malware)


Malware-1446109640.jpg

Malware[edit]

Info The integrity of the host is a critical part of the system's Trusted Computing Base [archive]. If the host system is compromised by malware [archive], so is every Whonix ™ virtual machine, Tor process and communication thought to be anonymous.

Introduction[edit]

Info Reminder: Whonix ™ is not perfect. The security, anonymity and privacy issues facing society are great, but there are few volunteers who are seriously investing the effort to challenge and resolve them.

If you are reading this page, then it is safe to assume being anonymous (less unique), and remaining so is of great interest. Users with a serious intention to research these issues are encouraged to assist in accordance with their skills. Testing, bug reporting or even bug fixing are laudable endeavors. If this process is unfamiliar, understand that about thirty minutes is required per message / identifier to ascertain if the discovered result [1] is a false positive, regression, known or unknown issue.

To date, none of the various leak testing websites running inside Whonix-Workstation ™ were ever able to discover the real (external), clearnet IP address of a user during tests. This held true even when plugins, Flash Player and/or Java were activated, despite the known fingerprinting risks. Messages such as "Something Went Wrong! Tor is not working in this browser." [2] (from about:tor) or "Sorry. You are not using Tor." (from check.torproject.org) are in most cases non-issues. If the real, external IP address can be revealed from inside Whonix-Workstation ™, then this would constitute a serious and heretofore unknown issue (otherwise not).

It is unhelpful to ask questions in forums, issue trackers and on various mailing lists with concerns that have already been discussed, or which are known issues / false positives. In all cases, please first search thoroughly for the result that was found. Otherwise, the noise to signal ratio increases and Whonix development is hindered. Users valuing anonymity don't want this, otherwise this would violate the aforementioned assumption.

If something is identified that appears to be a Whonix ™-specific issue, please first read the Whonix Free Support Principle before making a notification.

The Importance of a Malware Free System[edit]

Malware has malicious intent and can potentially: [3]

  • View and take snapshots of the desktop.
  • Peruse files and folders.
  • Gain access to protected data when decrypted.
  • Exfiltrate, corrupt or destroy data (particularly financial and personal information).
  • Plant fabricated evidence.
  • Damage operating system functionality.
  • Encrypt the contents of a drive(s) and demand payment for decryption (ransomware [archive]).
  • Display unwanted advertising.
  • Install unwanted software.
  • Install persistent rootkits [archive] or backdoors [archive].
  • Track browsing and other behaviour.
  • Remotely turn on webcams and microphones.
  • Create "zombie" computers which form part of a botnet for spam email, DDOS attacks [archive] or the hosting of illicit / illegal material which might result in getting SWATted [archive].
  • Record everything a user types, sends and receives.

Compromise Indicators[edit]

If trivial changes are noticed on your system -- such as a duplicate desktop icon -- this is not evidence of a hack or leak. Similarly, if warning or error messages appear that are difficult to understand, in most cases there is no need for panic. If something unexpected occurs such as the appearance of a "htaccess file in home directory", or graphical glitches emerge in Nyx, then it is more likely a harmless bug and/or usability issue rather than a compromise.

Skilled attackers do not leave such obvious traces of their breach. An infection by tailored malware is more plausible in this scenario and this is virtually impossible to detect by reading random messages in system logs. Even malware that is bought off-the-shelf (malware building toolkits) are unlikely to be discovered by cursory inspections. [4] Rootkit [archive] technology is no doubt a standard feature of the various programs.

Strange files, messages or other system behavior could feasibly relate to an attacker wanting the user to find something. However, the likelihood of this kind of harassment is considered low. Script kiddies [archive] ("skiddies") are unskilled attackers who uses scripts or programs to conduct attacks on computer systems and networks, most often with juvenile outcomes. For example, they might use programs to remotely control poorly-secured Microsoft Windows desktops, trolling their victims from an open, forced chat window, opening their DVD drive and so on. It is improbable that skiddies can achieve similar exploits against Linux, Xen or BSD platforms. [5] Sophisticated attackers (which are likely to use tailored malware) generally avoid detection, unless the user is unlucky enough to be a victim of Zersetzung [archive] (a psychological warfare technique).

Every forum post and support request requires time that could otherwise be directed to Whonix ™ development. Unless there is genuine evidence of a serious and credible problem, there is no need for a new post. This is also Support Request Policy (rationale). Developers and the Whonix ™ community at large do not have enough time to explain every message that Linux might report. In most cases, they are not important and outside the control of Whonix ™ developers.

Related:

Targeted Malware vs Off-The-Shelf Malware[edit]

Targeted malware is the opposite of off-the-shelf malware.

Targeted malware is specifically crafted against a known target to attack a specific system or limited amount of systems only with the goal to avoid detection by avoiding getting installed on too many where qualified people might detect the malware and publish about it.

On other other hand, off-the-shelf malware attempts to spread in bulk against bigger groups or the general public with the goal of taking over as many systems as possible.

The Utility of Antivirus Tools[edit]

Antivirus products and personal firewalls [archive] are not drop in solutions for a secure host. Malware can often stay undetected and evade scans, while application level personal firewalls are often circumvented. [6] Polymorphic code [archive] and rootkits [archive] essentially render antivirus products helpless. [7] [8]

The following paragraph is currently being discussed. [archive]

Antivirus tools are actually worse than useless. In the case of sophisticated and targeted attacks, the antivirus software can serve as a pathway to exploiting a system's kernel, since they almost always run with administration level privileges. [9] Antivirus software also harms privacy by sending system files back to the company servers for analysis.[10] The software also actively conducts man-in-the-middle attacks on secure SSL connections, enabling very sensitive information to be viewed. [11]

Preventing Malware Infections[edit]

The optimal scenario is to avoid infection by malware in the first place. Once malicious code has accessed a system, it is next to impossible to contain. Sensible steps include: hardening the operating system, carefully vetting programs and files that are retrieved from the Internet, and using hypervisors (virtualizers) to isolate software that processes untrusted data.

In the event a system compromise is strongly suspected or confirmed, the ultimate goal is to re-establish a trusted, private environment for future activities -- see Compromise Recovery for techniques to recover from host and/or Whonix ™ VM infections.

Detecting Malware Infections[edit]

Detecting off-the-shelf (standardized) malware is a very hard problem and conceptually a lost cause. If uncustomized malware is widespread enough, then it has a chance of being detected by a technician. Targeted malware might also get detected by a technician, but the likelihood is low unless they are lucky or gifted.

Non-technical users do not have many good options. They can either:

  • Spend a few years to rapidly increase their knowledge base of operating systems, network protocols, package analysis, programming, disassembly etc., and then try their luck.
  • Pay exorbitant sums to a technician to try and find system malware, even though there is no certainty of success. [12] [13]
  • Or seek the voluntary assistance of a technician to find malware, if they are both a high value target and have a reasonable rationale for why they are likely compromised. [14]

Watering Hole Attacks[edit]

It should be noted that advanced malware can infect a user's computer via a Watering Hole Attack [archive]. This vector has similarities to the software version of a Supply Chain Attack, and these methods are not mutually exclusive: [15]

A watering hole attack is a malware attack in which the attacker observes the websites often visited by a victim or a particular group, and infects those sites with malware. A watering hole attack has the potential to infect the members of the targeted victim group. Although uncommon, a watering hole attack does pose a significant threat to websites, as these attacks are difficult to diagnose.

In the case of (Qubes-)Whonix ™ users, any future attempt would logically target hosted content on GitHub, SourceForge, various forum locations, mirrors, popular documentation links, and frequently visited security and anonymity sites like Tails, The Tor Project and so on. [16] The hope is that developers, contributors and general users of the software become infected with stealthy malware that is immune to detection.

The attack involves a few steps: [15] [17]

  1. Zero-day or other vulnerabilties target the website software.
  2. Malicious JavaScript or HTML are most often used to inject malicious programming code.
  3. The code redirects visitors to a different site that serves "malvertisments" or malware masquerading as legitimate software.
  4. Once installed, the malware can infect various members of the targeted group.

It should be noted that advanced adversaries are capable of gaining knowledge about the behavioral patterns of target groups -- where they congregate, topics of research, related interests, and handle mapping of anonymous networks. This generic browsing and membership knowledge, along with observed security practices, greatly narrows the number of specific sites that need be targeted and the suitable attack mode. One way to mitigate this threat is to rigorously inspect websites for malicious code.

Interested readers can learn about six recent watering hole attacks targeting the US, China, banks and other entities here [archive].

Firmware Trojans[edit]

Info Once a user is infected with very sophisticated malware that modifies low-level firmware, it is extremely difficult to detect in almost all cases.

Firmware infections should not be confused with hardware/circuit trojans [archive], which are malicious modifications made to machine components during the manufacturing process. Despite their sophistication, circuit trojans are not immune to detection. [18]

Virtualizers and Hardware Compromise[edit]

Virtualizers like Qubes, VirtualBox and KVM cannot absolutely prevent the compromise of hardware. Running all activities inside VMs is a very reasonable approach. However, this only raises the bar and makes it more difficult and/or expensive to compromise the whole system. It is by no means a perfect solution.

No distribution of Linux, BSD, Xen or any other variant can solve the issue of needing to dispose of potentially infected hardware. Hardware-specific issues can really only be fixed at the hardware level. At best, software interventions can only provide workarounds.

The Promise of Libre Firmware[edit]

The problem is no hardware exists that consists of entirely Libre firmware. It is very difficult to analyze the firmware [archive] of hardware, wipe potentially compromised versions, or overwrite firmware with a most-likely-clean version.

Even if a user wholly depended on Libre firmware, this would only make verification easier but it could not stop infection. Disassembling hardware components -- BIOS, disk controllers, CPU, Intel AMT and so on -- and flashing them with clean versions offline is extremely difficult. It is simply cheaper and more convenient to buy new hardware.

The bundling of undesirable anti-features like DRM in closed firmware is further evidence that Libre firmware is needed, in addition to Libre hardware designs [archive].

A hypothetical stateless computer [19] [20] would solve the problem of malware persistence, but it still could not protect against the damage (data-exfiltration) caused by successful exploitation.

Backdoors[edit]

Table: Finding Backdoors in Freedom Software vs Non-Freedom Software

Non-Freedom Software (precompiled binaries) Freedom Software (source-available)
Can view original source code No Yes
Compiled binary file can be decompiled into disassembly Yes Yes
Regular pre-compiled binaries. Depends. Some use binary obfuscators. Yes
Usually not using obfuscation [archive] (anti-disassembly, anti-debugging, anti-VM [21]) Depends. Some use. Yes [22]
Price for security audit looking for backdoors very high [23] lower
Difference of precompiled version versus self-compiled version unavailable [24] small or none [25]
No requirement for reverse-engineering [archive] No Yes
Assembler language skills required much more less
Always legal to decompile / reverse-engineer No [26] [27] Yes [28]
Possibility catching backdoors through observing incoming and outgoing internet connections very difficult [29] very difficult [29]
Convenience of spotting backdoors lowest convenience [30] very high convenience [31]
Difficulty of spotting a "direct" backdoors [32] [33] [34] much higher difficulty [35] much lower difficulty [36]
Difficulty of spotting a bugdoor [37] very much higher difficulty [38] lower difficulty
Third parties can legally software fork [archive], release a patched version without the backdoor No [39] Yes [40]
Third parties can possibly make (possibly legally questionable) modifications such as disabling serial key checks [41] Yes Yes
Can always modify the software No [42] Yes
Third parties can use static code analysis tools No Yes
Third parties can judge source code quality No Yes
Third parties can find logic bugs in the source code No Yes
Third parties can find logic bugs in the disassembly Yes Yes
Can benefit from worldwide wisdom of the crowd No Yes
Third parties can benefit from debug symbols [archive] during analysis Depends. Some may publish debug symbols. Yes
Display source code intermixed with disassembly No Yes [43]
Effort to audit subsequent releases almost same [44] usually lower [45]
forum discussion [archive]

Spotting backdoors is already very difficult in Freedom Software where the full source code is available to the general public. Spotting backdoors in non-freedom software, obfuscated binaries is much exponentially more difficult. [46] [47] [48] [49] [50] [51] [52] [53]

To further improve the situation in the future, the Freedom Software community is working on the Reproducible Builds [archive] project. Quote:

Reproducible builds are a set of software development practices that create an independently-verifiable path from source to binary code.

Whilst anyone may inspect the source code of free and open source software for malicious flaws, most software is distributed pre-compiled with no method to confirm whether they correspond.

This incentivises attacks on developers who release software, not only via traditional exploitation, but also in the forms of political influence, blackmail or even threats of violence.

This is particularly a concern for developers collaborating on privacy or security software: attacking these typically result in compromising particularly politically-sensitive targets such as dissidents, journalists and whistleblowers, as well as anyone wishing to communicate securely under a repressive regime.

Whilst individual developers are a natural target, it additionally encourages attacks on build infrastructure as an successful attack would provide access to a large number of downstream computer systems. By modifying the generated binaries here instead of modifying the upstream source code, illicit changes are essentially invisible to its original authors and users alike.

The motivation behind the Reproducible Builds project is therefore to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process. By promising identical results are always generated from a given source, this allows multiple third parties to come to a consensus on a “correct” result, highlighting any deviations as suspect and worthy of scrutiny.

This ability to notice if a developer has been compromised then deters such threats or attacks occurring in the first place as any compromise would be quickly detected. This offers comfort to front-liners that they not only can be threatened, but they would not be coerced into exploiting or exposing their colleagues or end-users.

Several free software projects [archive] already, or will soon, provide reproducible builds.

See Also[edit]

References[edit]

  1. From a browser test website, in a log file and so on.
  2. https://forums.whonix.org/uploads/default/original/1X/c2c9bb5dc7efee7a933dd00d3bf0c30c29c99daa.png [archive]
  3. https://en.wikipedia.org/wiki/Malware [archive]
  4. Interested readers can verify these claims by researching off-the-shelf malware building toolkits. They are dangerous to install for inexperienced users, but there is a wealth of information online such as screenshots and video tutorials.
  5. It is unclear if script kiddie programs are readily available for attacking non-Microsoft Windows users.
  6. https://www.grc.com/lt/leaktest.htm [archive]
  7. https://arstechnica.com/security/2014/05/antivurus-pioneer-symantec-declares-av-dead-and-doomed-to-failure/ [archive]
  8. A botnet author brags in this thread of writing unbeatable malware and trolling antivirus vendors. [archive]
  9. https://theintercept.com/2015/06/22/nsa-gchq-targeted-kaspersky/ [archive]
  10. https://www.schneier.com/blog/archives/2017/10/more_on_kaspers.html [archive]
  11. https://bugs.chromium.org/p/project-zero/issues/detail?id=978 [archive]
  12. The salary costs for a security researcher / malware analyst over an extended period rule this out for most individuals.
  13. https://forums.whonix.org/t/document-recovery-procedure-after-compromise/3296/12 [archive]
  14. Only a select group of people fall into this group, for instance, whistleblowers targeted and infected by targeted viruses. Experts might be located who are willing to conduct analysis pro bono; later publicizing their findings for the public benefit.
  15. 15.0 15.1 https://www.techopedia.com/definition/31858/watering-hole-attack [archive]
  16. More commonly attacks favor banks, large organizations and government offices due to the obvious political and profit motives.
  17. https://en.wikipedia.org/wiki/Watering_hole_attack [archive]
  18. https://en.wikipedia.org/wiki/Hardware_Trojan#Detecting_Hardware_Trojans [archive]
  19. https://blog.invisiblethings.org/2015/12/23/state_harmful.html [archive]
  20. https://github.com/rootkovska/state_harmful/blob/master/state_harmful.md [archive]
  21. https://resources.infosecinstitute.com/topic/anti-disassembly-anti-debugging-and-anti-vm/ [archive]
  22. An Open Source application binary could be obfuscated in theory but depending on the application, the context (it's not an Open Source obfuscators) that would be highly suspicious. An Open Source application using obfuscators would probably be criticized in public, get scrutinized, loose user trust.
  23. Because for non-freedom software which is usually only available as pre-compiled, possibly obfuscated binary (using an anti-decompiler):
    • auditors can only look at the disassembly and cannot compare a pre-compiled version from the software vendor with a self-compiled version from source code.
    • there is no well written, well commented, easily readable by design source code.
  24. Since there is no source code, one cannot self-build one's own binary.
    • small: for non-reproducible builds (or reproducible builds with bugs)
    • none: for reproducible builds
  25. License agreements of proprietary software often expressively forbid decompilation.
  26. Skype used DMCA (Digital Millenium Copyright Act) to shut down reverse engineering of Skype [archive]
  27. Decompilation is always legal, permitted in the license agreements of Freedom Software.
  28. 29.0 29.1 This is very difficult since nowadays by default most outgoing connections are encrypted by default. At some point the content must be available to the computer unencrypted, in plain text, but accessing that is not trivial. When running a suspected malicious application, one cannot trust local traffic analyzers such as wireshark since the malicious application might have compromised the host operating system and hiding that information from the traffic analyzer or through a backdoor. An option might be running the application inside a virtual machine but many malicious applications actively attempt to detect virtual machines and if detected, avoid doing malicious things to avoid detection. Ultimately this might be possible, but very difficult.
  29. One has to decompile the binary and read "gibberish" or try to catch malicious traffic originating from the software under review. How many people decompiled for example Microsoft Office and kept doing that for every upgrade?
  30. One can:
    1. Audit the source code to be free of backdoors.
    2. Compare the precompiled binary with a self-build binary, audit the difference. Ideally, and in future, no difference (thanks to reproducible builds project) or small difference (due to non-determinism introduced during compilation such as timestamps).
  31. "direct" backdoor: Such as a hardcoded username and password or login key only known by the software vendor. No plausible deniability for the software vendor.
  32. List of “direct” backdoors in wikipedia [archive].
  33. One interesting “direct” backdoor was this bitcoin copay wallet backdoor.
  34. Requires strong disassembly auditing skills.
  35. If for example hardcoded login credentials where in the published source code, that would be easy to spot. If the published source code is different from the actual source code used by the developer to compile the binary, that difference would stand out when comparing pre-compiled binaries from the software vendor with self-compiled binaries from by an auditor.
  36. bugdoor: A vulnerability that can be abused to gain unauthorized access. Provides plausible deniability for the software vendor. See also Obfuscated C Code Contest [archive].
  37. Such issues are hard to spot in the source code but even harder to spot in the disassembly.
  38. Forbidden in license agreement. Due to lack of source code, no serious development is possible.
  39. Since source code is already available under a license that permits software forks and redistribution.
  40. This entry is to differentiate from above legally software fork. Precompiled proprietary software is often modified by third parties such as for purposes of privacy, game modding, exploitation.
  41. For example, Intel ME could not be disabled in Intel CPUs yet, neither is there a Freedom Software re-implementation of Intel Microcode at time of writing.
  42. One could review the disassembly but for subsequent releases that’s duplicating the effort. The disassembly isn’t optimized to change as little as possible or to be human understandable. If the compiled added new optimizations, compilation flags changed, that creates a much bigger diff [archive] of the disassembly.
  43. After the initial audit of a source-available binary, one can follow changes of the source code. To audit any newer releases, an auditor can compare the source code of the initially audited version with the new version. Unless there was a huge code refactoring or complete rewrite, the effort the audit subsequent versions is lower.
  44. The assembler low level [archive] programming language is more difficult than other higher level abstraction [archive] programming languages according to most people saying discussing it on the internet. Example web search terms: assembler easy, assembler easier, assembler difficult.
  45. Source code written in higher level abstraction programming languages such as C and C++ are compiled to object code [archive] using a compiler. See this article [archive] for an introduction and this image [archive]. Source code written in lower level abstraction programming language assembler is converted to object code using an assembler. See same article and this image [archive]. Given a reasonably complex program that was written in C or C++, where the source code is unavailable, reverse engineering is very difficult. That can be deducted from the high price for it. It is possible decompile (meaning re-convert) the object code back to C with a decompiler such as for example Boomerang [archive]. Quote Boomerang: Help! I've lost my source code [archive], which is putting a price tag on it:

    How much will it cost? You should expect to pay a significant amount of money for source recovery. The process is a long and intensive one. Depending on individual circumstances, the quality, quantity and size of artifacts, you can expect to pay upwards of US$15,000 per man-month.

  46. Try to solve the question of how to disassemble a binary (byte code) into assembly source code and re-assemble (convert) to binary? 1. Take a hello world assembler source code. 2. Assemble.
    nasm -felf64 hello.asm

    3. Link.

    ld hello.o -o hello

    4. objdump (optional).

    objdump -d hello

    5. Exercise for the reader: disassemble hello and re-assemble.

  47. The GNU Hello [archive] program source file hello.c [archive] at time of writing contains 170 lines. The objdump -d /usr/bin/hello on Debian buster has 2757 lines.

    Install hello.

    1. Update the package lists.

    sudo apt-get update

    2. Upgrade the system.

    sudo apt-get dist-upgrade

    3. Install the hello package.

    Using apt-get command line parameter --no-install-recommends is in most cases optional.

    sudo apt-get install --no-install-recommends hello

    The procedure of installing hello is complete.

    objdump -d /usr/bin/hello

    2757
    
  48. See for example how difficult it was to reverse engineer Skype. Skype Reverse Engineering : The (long) journey ;).. [archive]
    • Take all the Debian package maintainer scripts. Are these easier to review as is, most of them are written sh or bash or if these are converted to a program written in C, closed source, precompiled?
    • Do we prefer if OnionShare stays written in python, Open Source or do we prefer the project turned into a precompiled binary?
  49. salary comparison
  50. How much does a security audit cost reverse engineering vs source-available?


text=Jobs in USA
Jobs in USA


Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki


Follow: 1024px-Telegram 2019 Logo.svg.png Iconfinder Apple Mail 2697658.png Twitter.png Facebook.png Rss.png Reddit.jpg 200px-Mastodon Logotype (Simple).svg.png

Support: 1024px-Telegram 2019 Logo.svg.png Discourse logo.png Matrix logo.svg.png

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate Whonix.png United Federation of Planets 1000px.png

Twitter-share-button.png Facebook-share-button.png Telegram-share.png link=mailto:?subject=Malware and Firmware Trojans&body=https://www.whonix.org/wiki/Malware_and_Firmware_Trojans link=https://reddit.com/submit?url=https://www.whonix.org/wiki/Malware_and_Firmware_Trojans&title=Malware and Firmware Trojans link=https://news.ycombinator.com/submitlink?u=https://www.whonix.org/wiki/Malware_and_Firmware_Trojans&t=Malware and Firmware Trojans link=https://mastodon.technology/share?message=Malware and Firmware Trojans%20https://www.whonix.org/wiki/Malware_and_Firmware_Trojans&t=Malware and Firmware Trojans

Do you wonder why Whonix ™ will always be free? Check out Why Whonix ™ is Freedom Software.

https link onion link

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.

Copyright (C) 2012 - 2021 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.

Whonix ™ is a derivative of and not affiliated with Debian [archive]. Debian is a registered trademark [archive] owned by Software in the Public Interest, Inc [archive].

Whonix ™ is produced independently from the Tor® [archive] anonymity software and carries no guarantee from The Tor Project [archive] about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint, Contact.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent.