In my ordinary life, I teach computer science at the University of Applied
Sciences in Mannheim but for some months, I was an intern at ERNW learning a lot
about IT security and penetration testing. One of these learnings is that old
protocols can be fun and breaking them even more. But let’s start at the
beginning of the story…
Recently, I had a brief look at the Froala WYSIWYG HTML Editor (v3.2.0) as there
was a
post
about it on the Full Disclosure mailing list.
When targeting a HTML Editor, I guess one of the first things that everybody
does is to check for XSS vulnerabilities. So I tried the usual XSS payloads (a
great resource for XSS payloads is the
XSS cheat sheet
by PortSwigger) within the editor’s code view, but did not have much luck with
the common payloads as they were filtered. However, using the HTML object tag,
it was possible to trigger an XSS.
OpenSIS is an open source student information system.
Recently, it was affected by several vulnerabilities such as SQL injections,
local file inclusions and incorrect access controls
(CVE-2020-13380,
CVE-2020-13381,
CVE-2020-13382,
CVE-2020-13383).
That is why I got interested and also had a quick look at the application.
As part of this investigation, I discovered two vulnerabilities, an XSS
vulnerability (CVE-2020-27409) in the file SideForStudent.php that got quickly
fixed after being reported (see commit
edca085
for the details; the commit is included in release v7.5) and some incorrect
(i.e. non-existent) access controls for the password change functionality
(CVE-2020-27408). In this blog post, I would like to focus on the second
vulnerability and describe the tedious disclosure process that – in the end –
lead to nothing but the implementation of some ineffective obfuscation
mechanism.
I should start by telling you that this post does not contain anything
fundamentally new. Hence, if you already know the tools mentioned in the title,
this post may probably not be for you. However, if you are not too familiar with
these tools and want to understand a little bit more on how they work together,
you should keep on reading.
First, let us get a high-level overview of the different tools. We begin with
QEMU. QEMU is a piece of software to emulate hardware
such as processors. Imagine, for example, that you are running an operating
system such as Linux or Windows on a x86-64 machine and that you would like to
analyze a binary that has been compiled for an ARM or MIPS processor. Of course,
you can use static analysis on the binary, but if you want to find out more
about the runtime behavior, well, it would be good to have a corresponding
runtime environment.
During security assessments we sometimes obtain access to a restricted shell on
a target system. To advance further and gain complete control of the system, the
next step is usually to break out of this shell. If the restricted shell
provides access to certain system binaries, these binaries can often be
exploited to perform such a break out. Here we would like to show an interesting
example of such a break out by using the tcpdump binary.
Again, Cisco released security advisories for their software-defined networking
(SDN) solution called Application Centric Infrastructure (ACI). As before (see
blog post
here),
the published advisories originated from research performed in our ACI lab.
Yesterday, Cisco released a number of security advisories. Three of the
advisories originated from research performed by us for the Cisco Nexus 9000
Series Fabric Switches / Cisco Application Centric Infrastructure (ACI).
More specifically, these advisories are the following:
Once again Troopers will have its Windows & Linux Binary Exploitation workshop.
Its main focus are the ever-present stack-based buffer overflows still found in
software today (e.g. CVE-2018-5002, CVE-2018-1459, and CVE-2018-12897) and their
differences with regard to exploitation on Windows and Linux systems. If you
ever wanted to know the details of the exploit development process for these
systems then this workshop is for you.
After initial exercises involving the exploitation of classic stack-based buffer
overflows, modern defense mechanism such as Stack Cookies, DEP, and ASLR are
presented and analyzed for weaknesses. The participants will learn how these
defense mechanisms can be bypassed and will develop exploits targeting real
world applications such as the Foxit Reader Plugin for Firefox, Wireshark, and
nginx.
During a recent customer project we identified several vulnerabilities in the
VMware vRealize Automation Center such as a DOM-based cross-site scripting and a
missing renewal of session tokens during the login. The vulnerabilities have
been disclosed to VMware on November 20th, 2017. A security advisory for the
vulnerabilities has been made available
here on April
12th, 2018.
Just a few words regarding the cross-site scripting vulnerability. This
vulnerability is present within a GET request to the URL /vcac/gadgets/ifr
because of certain URL parameters whose values are directly passed to an eval
function call. The vulnerable parameters are gwt:onLoadErrorFn and
gwt:onPropertyErrorFn. It seems that these parameters are actually never used
by the application and we only found them by looking at the source code.
Last year I encountered a slight variation of an internal port scan
vulnerability for the CrystalReports component of SAP Business Objects. The
original vulnerability was presented and disclosed by rapid7 in the talk
“Hacking SAP Business Objects”. The corresponding slides can be found
here.
Basically, the original vulnerability allowed port scanning of (internal)
systems via the URL
http://hostname/CrystalReports/viewrpt.cwr?id=$ID&wid=$WID&apstoken=ip:port@$TOKEN.
By accessing this URL, different responses were received depending on if the
port (parameter port in the URL) of the system (parameter ip in the URL) was in
the state “open” or “closed”. The original vulnerability has been fixed a long
time ago (SAP security note 1432881), but the fix did allow for a slight
variation to make the attack work again.