<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>exploit on Rich Mirch</title>
    <link>https://blog.mirch.io/tags/exploit/</link>
    <description>Recent content in exploit on Rich Mirch</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 20 May 2022 14:50:25 +0000</lastBuildDate>
    <atom:link href="https://blog.mirch.io/tags/exploit/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Exploiting Kaseya Unitrends Backup Appliance – Part 1</title>
      <link>https://blog.mirch.io/2022/05/20/exploiting-kaseya-unitrends-backup-appliance-part-1/</link>
      <pubDate>Fri, 20 May 2022 14:50:25 +0000</pubDate>
      <guid>https://blog.mirch.io/2022/05/20/exploiting-kaseya-unitrends-backup-appliance-part-1/</guid>
      <description>&lt;p&gt;In 2021 I discovered several high and critical vulnerabilities in the &lt;a href=&#34;https://www.unitrends.com/&#34;&gt;Kaseya Unitrends&lt;/a&gt; backup appliance. This research was conducted and published as part of my day job. Part one details a chain of vulnerabilities by leveraging an insecure &lt;a href=&#34;https://www.postgresql.org/&#34;&gt;PostgreSQL&lt;/a&gt; database to ultimately gain shell access to the remote server. Visit &lt;a href=&#34;https://www.cyberonesecurity.com/blog/exploiting-kaseya-unitrends-backup-appliance-part-1&#34;&gt;https://www.cyberonesecurity.com/blog/exploiting-kaseya-unitrends-backup-appliance-part-1&lt;/a&gt; for the full write-up. Stay tuned for part two.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Metasploit module developed for CVE-2018-18556 VyOS Privilege Escalation</title>
      <link>https://blog.mirch.io/2020/09/25/metasploit-module-developed-for-cve-2018-18556-vyos-privilege-escalation/</link>
      <pubDate>Fri, 25 Sep 2020 20:52:25 +0000</pubDate>
      <guid>https://blog.mirch.io/2020/09/25/metasploit-module-developed-for-cve-2018-18556-vyos-privilege-escalation/</guid>
      <description>&lt;p&gt;Today, a Metasploit module was merged for a vulnerability I found in 2018 with &lt;a href=&#34;https://www.vyos.io/&#34;&gt;VyOS&lt;/a&gt;. This vulnerability was my first public InfoSec blog post. I appreciate &lt;a href=&#34;https://github.com/bcoles&#34;&gt;bcoles&lt;/a&gt; for developing the &lt;a href=&#34;https://github.com/rapid7/metasploit-framework/pull/14123&#34;&gt;exploit/linux/ssh/vyos_restricted_shell_privesc&lt;/a&gt; module. Read the &lt;a href=&#34;https://www.rapid7.com/blog/post/2020/09/25/metasploit-wrap-up-80/&#34;&gt;Metasploit Wrapup for 9/25/2020&lt;/a&gt;. The full write-up can be found on this blog at &lt;a href=&#34;https://blog.mirch.io/2018/11/05/cve-2018-18556-vyos-privilege-escalation-via-sudo-pppd-for-operator-users/&#34;&gt;CVE-2018-18556 – VyOS Privilege escalation via sudo pppd for operator users&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2018-1792 - IBM MQ Privilege Escalation: Fun with RUNPATH</title>
      <link>https://blog.mirch.io/cve-ibm-mq-privilege-escalation-fun-with-runpath/</link>
      <pubDate>Sun, 25 Aug 2019 16:37:18 +0000</pubDate>
      <guid>https://blog.mirch.io/cve-ibm-mq-privilege-escalation-fun-with-runpath/</guid>
      <description>&lt;h1 id=&#34;vulnerability-summary&#34;&gt;Vulnerability Summary&lt;/h1&gt;
&lt;p&gt;&lt;a href=&#34;https://en.wikipedia.org/wiki/IBM_MQ&#34;&gt;IBM MQ&lt;/a&gt; for Linux and UNIX systems is vulnerable to a privilege escalation attack by forcing a setuid root binary to load a malicious library. A local attacker with access to the mqm account can execute arbitrary code as root. In October 2018 IBM published an &lt;a href=&#34;https://www-01.ibm.com/support/docview.wss?uid=ibm10734447&#34;&gt;advisory&lt;/a&gt; along with patches for several versions.&lt;/p&gt;
&lt;p&gt;The goal of this post is to show how the &lt;a href=&#34;https://en.wikipedia.org/wiki/Rpath&#34;&gt;RPATH/RUNPATH&lt;/a&gt; value could potentially be leveraged for privilege escalation. When specified at compile time this path is embedded in the binary and is the first path searched when searching for a library if the dependent library specified does not contain a slash. Details on how this works can be found in the &lt;a href=&#34;http://man7.org/linux/man-pages/man8/ld.so.8.html&#34;&gt;ld.so&lt;/a&gt; man page.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2019-6724 : Barracuda VPN Client Privilege Escalation on Linux and macOS</title>
      <link>https://blog.mirch.io/2019/02/14/cve-2019-6724-barracuda-vpn-client-privilege-escalation-on-linux-and-macos/</link>
      <pubDate>Thu, 14 Feb 2019 15:31:43 +0000</pubDate>
      <guid>https://blog.mirch.io/2019/02/14/cve-2019-6724-barracuda-vpn-client-privilege-escalation-on-linux-and-macos/</guid>
      <description>&lt;p&gt;The barracudavpn component of the Barracuda VPN Client prior to version 5.0.2.7 for Linux, macOS, and OpenBSD runs as a privileged process and can allow an unprivileged local attacker to load a malicious library, resulting in arbitrary code executing as root.&lt;/p&gt;
&lt;p&gt;This post will walk through the process on how I found and exploited the vulnerability on Linux. The full PoC will also work on macOS. When researching for potential vulnerabilities with privileged binaries a test system should be used to avoid causing damage or negative impacts.&lt;/p&gt;
</description>
    </item>
    <item>
      <title>CVE-2018-18629: Keybase Linux privilege escalation</title>
      <link>https://blog.mirch.io/2018/12/21/cve-2018-18629-keybase-linux-privilege-escalation/</link>
      <pubDate>Fri, 21 Dec 2018 18:43:08 +0000</pubDate>
      <guid>https://blog.mirch.io/2018/12/21/cve-2018-18629-keybase-linux-privilege-escalation/</guid>
      <description>&lt;p&gt;Recently I started using &lt;a href=&#34;https://keybase.io/&#34;&gt;Keybase&lt;/a&gt; which is a Slack-like application but provides end-to-end encryption. Version 2.8.0.20181017144746.3efc4cbf3c is vulnerable to a privilege escalation vulnerability allowing a low privileged user to execute arbitrary commands as root.&lt;/p&gt;
&lt;p&gt;After executing the application using a low privileged account I noticed a process named keybase-redirector running as root. I was interested and wanted to understand how this worked. After checking the file permissions I found that the keybase-redirector was setuid root. I enjoy the challenge of finding vulnerabilities in privileged binaries so I started my research.&lt;/p&gt;</description>
    </item>
    <item>
      <title>CVE-2018-19788 PoC - polkit: Improper handling of user with uid &amp;gt; INT_MAX leading to authentication bypass</title>
      <link>https://blog.mirch.io/2018/12/09/cve-2018-19788-poc-polkit-improper-handling-of-user-with-uid-int_max-leading-to-authentication-bypass/</link>
      <pubDate>Sun, 09 Dec 2018 19:32:04 +0000</pubDate>
      <guid>https://blog.mirch.io/2018/12/09/cve-2018-19788-poc-polkit-improper-handling-of-user-with-uid-int_max-leading-to-authentication-bypass/</guid>
      <description>&lt;p&gt;While reviewing my Twitter feed I noticed a recent popular tweet from &lt;a href=&#34;https://twitter.com/0xdea&#34;&gt;@0xdea&lt;/a&gt;.
&lt;a href=&#34;https://twitter.com/0xdea/status/1070308598146850818&#34;&gt;https://twitter.com/0xdea/status/1070308598146850818&lt;/a&gt;
I was intrigued and wanted to see if there was a way to leverage this to execute arbitrary code as root.&lt;/p&gt;
&lt;p&gt;First we need to understand what the value of INT_MAX is. Fortunately the getconf command can be used to find the value or you can find it in /usr/include/limits.h.&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;o&#34;&gt;[&lt;/span&gt;root@localhost ~&lt;span class=&#34;o&#34;&gt;]&lt;/span&gt;&lt;span class=&#34;c1&#34;&gt;# getconf INT_MAX&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;m&#34;&gt;2147483647&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;o&#34;&gt;[&lt;/span&gt;root@localhost ~&lt;span class=&#34;o&#34;&gt;]&lt;/span&gt;&lt;span class=&#34;c1&#34;&gt;# grep &amp;#39;define INT_MAX&amp;#39; /usr/include/limits.h&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;c1&#34;&gt;# define INT_MAX 2147483647&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;To exploit the vulnerability the user must have a UID value larger than 2147483647. I used the same value of 4000000000 that &lt;a href=&#34;https://twitter.com/0xdea&#34;&gt;@0xdea&lt;/a&gt; posted.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
