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.