Vertical Privilege Escalation: Exploiting nmtui Sudo Misconfiguration

Privilege escalation vulnerabilities are still a major target for attackers looking to breach sensitive systems. Let’s take a look at a specific vertical privilege escalation example, where misconfigured sudo permissions let a low-privileged user run the nmtui tool without needing a password. By using the JSON import feature in Add Team, we can exploit this to escalate our privileges and get ourselves a root shell. 

So, there’s a bit of a security issue with how sudo was set up in this case. It lets users with low privileges run nmtui (the Network Manager Text User Interface) as if they were root. Here’s the deal: by playing around with the JSON import feature in the Add Team section of nmtui, it kicks off a vi editor session with root privileges. If someone manages to escape from vi into a shell, they can elevate their permissions all the way to root.

Happy hacking #1337

Step-by-Step Exploitation Guide

Follow these steps to reproduce the vulnerability:

1. Use a terminal session where the current user has limited privileges.
2. Execute nmtui with sudo.
3. sudo nmtui
4. Edit a connection.
   
   
   
   
   
5. Select "Add".
6. Navigate to the Add option in the nmtui menu.
   
7. Add a Team.
8. Proceed by selecting the Add Team option.
   
   
   
   
   
9. Choose the JSON option.
   
   
   
   
   
10. In this step, nmtui attempts to import a JSON configuration, opening the vi editor in a root context.
11. Escape from vi to a shell.
12. Use the following command within vi to spawn a root shell:
13. :!/bin/bash
14. You are root!
    
    

*This behavior is further exploitable if nmtui is configured with the setuid (SUID) bit, allowing any user to execute it with elevated privileges.

Reverse Engineering Insights

The attack was uncovered during a reverse engineering analysis of nmtui using Ghidra, a popular software reverse engineering tool developed by the NSA. The analysis revealed that the JSON import functionality in nmtui invokes the vi editor, creating a security loophole in this case. 

As I did not have much time to explore it further, other nmtui features might call the vi.

References

Tools and Techniques:

• Ghidra: Reverse engineering tool used to analyze nmtui.
• Sudo: A powerful tool to allow users to execute commands with elevated privileges.
• SUID: A Unix/Linux file permission that allows users to execute a file with the permissions of the file owner.
  

Related Escalation Techniques:

• Privilege Escalation with vi: Learn more about escaping from vi into a shell in the GTFOBins repository. also https://medium.com/@pettyhacks/linux-privilege-escalation-via-vi-36c00fcd4f5e

The curious case of XSS and the mouse middle button.

Hi guys! Today I will share my experience of how I exploited an XSS in a pretty particular scenario. 

During analysis, there was a feature on the application that allows the customer to add external reference links for specific options.

So, there were input filters not allowing double quotes, <,>, and other chars. The injection would happen only in the href parameter.

Basically: 

<a href="<xss_here>" target="_blank">ClickMe</a>

At this point, I thought, piece of cake, I will inject a standard payload like javascript:alert(1), and that's it, exploited! 

<a href="javascript:alert(1)" target="_blank">ClickMe</a> Right?

 

WRONG! 

As you know, the "target" parameter controls the window link behavior. 

In this case, it forces the link to open in a new tab due to the _blank value. When you left-click (the usual behavior), on the link, even with the javascript:alert(1) payload, the browsers handle it differently:

Firefox: Opens a new blank tab with the payload on the URL address bar

 

Chrome and Edge: Open a new blank tab with about:blank#blocked on the URL address bar. 

So, based on this behavior, it's clear it cannot be exploited just by left-clicking on the link.

I tried to change the target parameter value using javascript, but the instruction to open a new tab executes first, so there is no way to rewrite the value on the fly. 

After some research, I found these links https://bugzilla.mozilla.org/show_bug.cgi?id=55696 and https://support.mozilla.org/en-US/questions/1289787 related to new tab/window and javascript execution. Then the idea to use the mouse middle button popped up, and BANG!  

By default, the browsers(Firefox, Chrome, and Edge) have the middle button configured to force open links in a new tab. So, by using this button, the browsers executed the Javascript! Also, this time, the behavior was slightly different, and it can interfere during the exploitation. To test these conditions, I changed the payload to javascript:alert(document.cookie) 

Firefox: The browser executed the javascript in a new blank tab. However, the javascript could not read the cookie, as expected, due to run in a blank tab out of the application context.

Chrome and Edge: The browsers weirdly did not open a new tab, even forced by the middle button. So, the javascript is executed in the application context. That is, it can read the application cookies.

That's all, folks! Cya!