Monday, March 19, 2018

Abusing Text Editors Via Third-Party Plugins

Abusing Text Editors Via Third-Party Plugins

Software third-party extensibility mechanisms have proven to be fertile ground for attacks many times in the past.Following recent attacks of such nature, we started examining 6 popular extensible text editors for unix systems, checking their defenses against similar potential abuses.
This research document outlines how some of them can be abused locally for privilege escalation. Mitigating this potential breach can be done in several ways; we provide OSSEC rules for your own convenience.
Abusing Text Editors Via Third-Party Plugins
While there are other known techniques to escalate privileges, specific restrictive circumstances might make this one the preferred choice.

Advanced editors give you more features, ease of use and most importantly for our scope - they offer extensibility. Cutting to the chase, extensibility means running some third-party bits of code. That third party may be yourself, or a developer that made his extension public (published in a web store, git repo...).

Technical users will occasionally need to edit root-owned flies, and for that purpose they will open their editor with elevated privileges, using “sudo”. There are many valid reasons to elevate the privileges of an editor.

SafeBreach Labs examined several popular editors for unix environments. Our research shows how extensible text editors can be used locally as another way to gain privilege escalation on the machine. We will demonstrate how our method succeeds regardless of the file being opened in the editor, so even limitations commonly applied on sudo commands might not
protect from it.

The set of editors that were put to the test include some of the most highly ranked ones (according to 
1. Sublime 
2. Vim 
3. Emacs 
4. Gedit 
5. pico/nano


What SafeBreach Labs found about most of the applications that we examined is that when it comes to loading plugins, their separation of the two modes-- regular and elevated--is not complete. Their folder permissions integrity is not kept well and that opens the door for an attacker with regular user permissions to get elevated execution of arbitrary code.

Imagine a startng point where an atacker has the ability to run code, not elevated. The user that he runs under is a sudoer (Linux), but running without elevated status. All he or she has to do is write a malicious plugin to the user folder of the editor that’s in use, and wait for the editor to be invoked in elevated status, where the user will enter his root password. Depending on the user profile, the attacker might only need to wait for hours. In some cases he may wait forever, but there are plenty of situations that require users to open flies using sudo.



For the privilege escalation to work, we assume the following:
• We have regular (not elevated) execution using a sudoer user (a user that’s in /etc/sudoers) • The user occasionally invokes the editor in elevated status - common amongst linux users, especially when the machine is a server. 
• The initial user the attacker takes use of has no malicious intentions. He or she has no intentions to exploit his or her sudo permissions to hack or break. If he or she was an insider threat, then of course this method is redundant. 
• Alternatively, the user may have malicious intentions, but the system administrator has restricted his sudo privileges to only specific commands and files.




Post a Comment

Popular Posts