# The way the attacker has escalated the privilege to root through taking advantage of the Sudo IPTables

## **Overview**

As you may know, in many Linux systems, administrators often configure `sudo` to grant users the ability to run specific commands without a password. One common tool given such permission is `iptables`, used to configure the firewall. But what happens if this permission is exploited to gain **full root access?**

This article will analyze the process of exploiting a seemingly harmless sudo permission to escalate privileges to root. Through this, we will see the importance of understanding the behavior of system commands and managing sudo policies more carefully.

![](https://www.shielder.com/img/blog/why_root.png align="center")

Once attackers gain root access, they can easily:

* Manipulate and control all processes running on the system, without user restrictions.
    
* Change network settings, open ports, run packet-sniffing programs, adjust iptables, spoof MAC/IP, etc.
    
* Sometimes "show off" their hacking skills or system control to friends—because root is not just technical, it's also a style.
    

## **Execution Context**

We need to understand that `iptables` configurations are stored using the following tools:

* `iptables-save`: exports the entire current iptables configuration as text.
    
* `iptables-restore`: reads the configuration file and re-establishes the entire iptables setup.
    

The question is: **does iptables support arbitrary code execution?**

The answer is **indirectly yes**, through the `xtables-addons` module or by interacting with special libraries or files in `/proc`. However, the more common and simpler way is to **use** `iptables` to overwrite root files or enable arbitrary code execution by combining it with a `shell script`.

![](https://www.shielder.com/img/blog/fusion.jpeg align="center")

## **Exploitation Method**

In recorded campaigns, analysts have identified two main exploitation techniques for escalating privileges to root.

**Technique 1: Overwriting** `/etc/passwd` **via** `iptables-save`

* As mentioned above, `iptables` allows comments to be added to rules through the `comment` module. When using `iptables-save`, these comments are recorded in the output. By inserting a fake line into the comment and overwriting `/etc/passwd`, an attacker can create a `root` user with a password of their choice.
    
* Initially, the attacker will create an encrypted password for `root`. The result will be an encrypted string.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1749182377750/39635247-7597-4e1e-8e41-63e40b0ad0f7.png align="center")
    
* Then the attacker will use the newly created encrypted string to deploy the fake line for `root` and add a Rule with a Comment containing the fake line.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1749182395222/ff906d77-49bf-4489-a0df-7d89e3111269.png align="center")
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1749182406216/cefea9a5-6d3b-43ef-a30b-b4812ffe323e.png align="center")
    
* Next, the attacker will use sudo to overwrite the `/etc/passwd` file with `iptables-save` and finally be able to log in with the newly created `root` user.
    
    ![](https://www.shielder.com/img/blog/iptables_passwd_overwrite.png align="left")
    

![](https://www.shielder.com/img/blog/iptables_privesc_successful.png align="center")

**Technique 2: Arbitrary Command Execution via** `--modprobe`

* When `iptables` needs to load a kernel module that isn't available, it uses `modprobe` to load that module. If it's possible to specify an arbitrary `modprobe` program, commands can be executed with `root` privileges.
    
* Initially, the attacker will create a malicious script on the system.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1749184287462/bdf74f60-2212-4562-b148-cb27a8cc9c3c.png align="center")
    
* The next step is for the attacker to use `iptables` with `--modprobe` to point to the script that was just created.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1749184485695/829c32a0-8315-4ae0-9714-fa35e7fd5897.png align="center")
    
* And finally, the attacker can execute a shell with `root` privileges.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1749184576196/96a1db77-0778-404c-a076-dc0bb9d6ebfb.png align="center")

Once the privilege escalation process is complete, the attacker will remove traces by deleting the added `iptables` rules and removing the files and scripts created during the exploitation process.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1749190414015/f74bbadb-3775-492b-bc8a-b79ed4500ad9.png align="center")

## **Conclusion**

`Sudo` privileges for `iptables` may seem harmless, but in reality, they can be exploited to gain root access on the system. Through this article, you have seen:

* How to understand and analyze sudo privileges.
    
* How to exploit `iptables` to write files or execute malicious code.
    
* Real-world privilege escalation techniques.
    

Therefore, organizations and users should always carefully check `sudo` privileges and system configurations to avoid falling victim to such exploits.

## **Recommendations**

1. **Do not grant** `sudo` **directly to** `iptables`
    
    * **Remove** `sudo` **access for** `iptables` unless absolutely necessary.
        
    * If required, use alternative solutions such as:
        
        * **iptables wrapper script** (a secure script that only allows a few basic rules).
            
        * Use `sudoers` with **specific options** to limit commands.
            
2. **Properly configure** `sudoers`
    
    * **Use** `NOEXEC` to block shell calls from programs:
        
        * Defaults!/sbin/iptables noexec
            
    * **Restrict executable paths (**`secure_path`):
        
        * Defaults secure\_path="/usr/sbin:/usr/bin:/sbin:/bin"
            
3. **Assign permissions appropriately**
    
    * Do not grant `ALL` permissions if not necessary.
        
    * Separate roles: network admin users should only have network permissions, not system permissions.
        
    * Use sudo by **group** instead of individual users.
        
4. **Regularly update the operating system and kernel**
    
    * sudo apt update && sudo apt upgrade -y # Debian/Ubuntu
        
    * sudo dnf update # RHEL/Fedora
        

## **References**

1. [Shielder - A Journey From <code>sudo iptables</code> To Local Privilege Escalation](https://www.shielder.com/blog/2024/09/a-journey-from-sudo-iptables-to-local-privilege-escalation/)
    
2. [Privilege Escalation on Unix – Lisandre](https://lisandre.com/archives/3142)