The Paranoid Schizophrenic’s Guide to the Linux Command Line

[Inspired by Ubuntu Forum's Malicious Commands warning]

If you're not careful, hackers can do this to your computer.

This guide covers a number of common Linux security flaws that make using the shell an unnecessarily risky experience.

For the security-conscious, choosing an open-source operating system like Linux should be simple common sense. The open-source development model encourages third-party scrutiny by its very nature, whereas closed-source models inherently mandate none. Companies often do little internal auditing, additionally prohibiting reverse-engineering through complex end-user license agreements.

The fact is that it’s very easy to corrupt a proprietary application from a security perspective: management decides on  a subversive feature and the developers are obliged to implement it, while in an open-source environment,  nobody has the final say. Those who strongly oppose a change may simply fork the project, and time will decide which project made the right decision. On the other hand, those who oppose questionable changes in a proprietary application are terminated by their employers via papers or private military corporations.

Contrary to public belief, large, current distributions are often a poor choice for security. As time goes by, projects are increasingly tainted by corporate and governmental interests, to the detriment of security-conscious users. Likewise, newer software is not necessarily better — New software is continually scrutinized for vulnerabilities, and as such is less secure than its long-forgotten predecessors. Without compromise, all users should find and use a suitably archaic set of software (such as Linux kernel 2.0) such that no new vulnerability analysis is taking place. Likewise, older software tends to be more compact — It is easier for a user to analyze the source of the Linux 2.0 than it is to read the millions of lines within Linux 2.6. However, being pragmatic, Ubuntu is a good choice because the upstream Debian patching often fixes software (and warps it in interesting ways) such that general-purpose exploits become infeasible.

When securing a distribution, there are a number of common pitfalls — applications that are often accepted by novices, yet carry a significant security risk with them. As any experienced, security-conscious user will tell you, the average default installation performed by many of the more user-friendly distributions is often lacking in security, catering more for general use. But what of the dangerous exploits that can turn your power supply into a bomb?

It looks innocent, but is your power supply plotting to kill you?

Below is a list of common applications that are responsible for the vast majority of damage inflicted during system compromises.

• ls: Many see ls as an innocuous command, useful for finding files within a directory and determining their attributes. However, this command is commonly replaced with malicious binaries due to the frequency with which it is invoked. I recommend moving the ls binary to a 16 or 32-character random location, such as /usr/bin/OGh1eoL2hDqZOBl8. To generate this with sufficient entropy, I asked an acquaintance afflicted with severe multiple personality disorder. As this string has been disclosed, it is now to be considered compromised and should not be used for security purposes.
• cp: Another seemingly innocuous command. In the dream land full of rainbows and marshmallows that most users concoct in their heads, cp is used to duplicate files. This may seem innocent, but in practice it is more often used for malicious ends. After a hacker has compromised the root account and finished compiling a malicious binary, he will use this to copy it into the place of an existing binary, an attack I mentioned in the last paragraph. A cp-savvy attacker is far more dangerous than one who only uses mv, as the former is capable of replacing multiple binaries at a time, and has a back-up in the event his activities are noticed.
• dd: While some will insist it can be useful, it should never be touched. A hacker can easily use this to erase the filesystem from one of your devices, or copy the filesystem of a malicious device onto your system. This utility is highly dangerous, being responsible for a large number of catastrophic data wipes, and is to be avoided at all costs. Any distribution that packages dd is ideally avoided. Note that this often means creating your own distribution, as dd is included in GNU Coreutils, a commonly-packaged suite of applications ranging from the mundane to the critically dangerous.
• cd: While technically a shell built-in, this highly damaging command deserves its own entry. While it would be beneficial to start users in a random, deeply-nested directory without a $PS1 (or pwd support), due to cd’s default behaviour of navigating to the home directory when called without arguments, this potentially useful security technique is rendered useless. Likewise, the tilde (~) expands to the home directory’s path, and it too is often used when compromising a system. Ideally, this command would not be compiled into the shell. The other dangerous link cd makes use of is “..”, which allows the shell to traverse up the directory tree without actually knowing the name of the parent directory. This is the equivalent of allowing a blind lunatic with a chainsaw into your home and playing Marco Polo with him.
• bash: Commonly used to interact with the computer in a text-based way. This is the most common shell on Linux systems, and as such, it facilitates the vast majority attacks. Capable of executing arbitrary commands and code, it alone is responsible for over 99% of the damage inflicted during attacks. You should remove this as a first step in securing your system, along with any fall-backs such as ‘ksh‘, ‘zsh‘, and ‘dash‘. Busybox, functioning as a minimal replacement for the shell and GNU Coreutils, is a better alternative, but remember: A system you can log into is a system you can compromise.

The file /etc/passwd contains important information about your users and their shells. An attacker reading this file now only has to guess the password of the user account, which makes username security worthless. Remove this and use a 32-character randomly-generated string for your username. Do not generate the username through /dev/urandom or any such device, as it is not a true random number source, producing pseudo-random output which can be predicted by severely obsessive-compulsive individuals like myself. Likewise, Internet servers providing so-called ’secure’ random numbers are likely fronts for governmental agencies interested in harvesting your data, so you should find your own source of entropy.

The Internet: An unnecessary security risk?

The Internet is the vector through which the vast majority of attacks occur. A common application which uses the Internet is the browser, which communicates over HTTP, typically using port 80. This port is commonly used by hackers to send malicious data to unsuspecting users, and as such you should read ‘man iptables‘ and drop all packets being sent to port 80 on your machine in order to reduce the chances of an attack. It is also wise to drop packets on 443, which is used by HTTP over TLS/SSL, a supposedly ’secure’ protocol utilizing government-vetted (and thus highly suspect) algorithms.

Remote access is another primary attack vector. So-called ’secure’ remote access utilities such as OpenSSH use algorithms such as RSA, DES and AES to secure their payloads, all of which were developed or analyzed by major governmental cryptography agencies, and as such are likely to have back doors allowing the government (and other knowledgeable, malicious entities) to read your confidential information as it is sent over the wire. I recommend xor and rot13 for maximum data security, as they are uncommon and thus your data will be secure. If you feel you need additional security, utilize rot14. While rot13 is able to be decoded in the same manner as it is encoded, rot14 must be run 26 times for the message to be deciphered. It is also possible to rot -1, but this is a highly sophisticated attack that few are capable of.

There is a directory on every machine, /usr/share/man, which contains information on much of the software you have installed. Through this facility, attackers can determine what you have installed, and compromise your system through vulnerabilities in these applications even if they aren’t running: That’s how deadly /usr/share/man can be. Keep in mind that man pages are created by the people who package software for your distribution, and sometimes by the upstream developers themselves.This is clear evidence of the system deliberately working  against the user. While it is impossible to determine whether your ‘rm‘ binary is intact, I suggest attempting to use it as such: ‘rm -rf /usr/share/man‘. If it has not been compromised, this directory will be removed and your system will be markedly more secure.

Hackers can also determine what you are running via the process list, and this cannot easily be stopped. You might try unplugging your ethernet cable, but due to electromagnetic emanations from your computer, data can be gathered without a direct connection and without a wireless networking device. At the lowest level, all attacks are facilitated by power. Be it 110 or 220V, 50 Hz or 60 Hz, on a 15, 20 or 30 amp circuit, without power, no attack is possible. The Paranoid Schizophrenic would thusly recommend unplugging your Linux machine to ensure data integrity and security, if it did not impact uptime in a negative manner. If you are particularly uncompromising, you may wish to do this. Data security is paramount for some, and this is one of the best ways to ensure it.

Commonly used by computer professionals, RAID, or “Redundant Array of Inexpensive Disks” is commonly used for a variety of reasons, ranging from increased speed to improved data security in the event of drive failure. I cannot condone RAID1, because it is then possible for an assailant to steal one of your drives without you being any the wiser. RAID0 is the optimal solution, across multiple disks and with multiple partitions per disk. This way, a drive failure (or damaging one drive in any way, such as airlifting the computer back to the Pentagon for analysis) is guaranteed to render the data unusable. You should pick a block size based on that you are storing — With small files, a large block size may be sufficient to store entire incriminating files. It’s recommended to use a very small block size in that case, such that the file, even if partially recovered from one drive, is useless.

At a very low level, there is also the file system. If you are running a newer file system such as ext3, ext4, or reiserfs, your computer may be SPYING on you. Everything is written to a ‘journal’ before being committed to the disk. Do you know anything about this journal? I thought not. In practice, this journal may be harvested and transmitted to governmental agencies who will be able to replay disk activity. Meta-data journaling is also an option, wherein entire files are not written to the journal — But this can still prove to be incriminating evidence. It is inadvisable to open your hard drive and have a go at the platters with a chisel, because it is difficult to identify the location of the journal.

J. R. "Bob" Dobbs: Can he be trusted?

Lastly… Can strangers be trusted? Can your friends be trusted? Can your mother be trusted? Can you be trusted? I think not. Under duress you may be willing to allow others to compromise your system, and that cannot be allowed. For perfect security, you should write your data onto floppy disks, bury them individually in crates across a large expanse, and then bludgeon yourself repeatedly in the head so that you cannot remember their locations.