In the last blog post, we discussed how fuzzers determine the uniqueness of a crash. In this blog post, we discuss how we can manually triage a crash and determine the root cause. As an example, we use a heap-based buffer overflow I found in GNU readline 8.1 rc2, which has been fixed in the newest release. We use GDB and rr for time-travel debugging to determine the root cause of the bug.
In August 2020 we reported six vulnerabilities in SolarWinds N-Central 12.3.0.670 to the vendor.
The following CVE IDs were assigned to the issues :
CVE-2020-25617: RCE in N-Central Administration Console (AdvancedScripts Endpoint)
CVE-2020-25618: Local Privilege Escalation from nable User to root (N-Central Backend Server)
CVE-2020-25619: Access to Internal Services through SSH Port Forwarding (N-Central Backend Server)
CVE-2020-25620: SolarWinds Support Account with Default Credentials
CVE-2020-25621: Local Database does not require Authentication (N-Central Backend Server)
CVE-2020-25622: CSRF in N-Central Administration Console (AdvancedScripts Endpoint)
The vulnerabilities have been found in the course of an extensive research project, in which we analyze the security of multiple Unified Endpoint Management (UEM) solutions. Similar vulnerabilities have been found in other solutions as we pointed out in previous posts about the Ivanti DSM Suite and Nagios XI. The final outcome of the research project will be published as a whitepaper and possibly conference talk as soon as the project including all disclosure processes concludes.
We will provide a short description of the CVEs outlining the impact of the vulnerabilities. Technical details will be published in a whitepaper as mentioned above. All six vulnerabilities have been verified for SolarWinds N-Central 12.3.0.670.
This blogpost sheds some light on how fuzzers handle crash deduplication and what a unique crash is for a fuzzer. For this, we take a look at two contrived examples and compare the unique crashes identified by AFL++ and honggfuzz.
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.
Microsoft has released a set of privacy settings for Office, one of which enables users to configure the type and amount of diagnostic (i.e., telemetry) data that Office may send to Microsoft. When deployed, it is available in the form of a group policy setting. It allows users to configure one of the following diagnostic data levels: required, optional, or neither. The report we produced:
analyzes the impact of the required, optional, and neither diagnostic data levels on the output of diagnostic data produced by Office; and
provides and evaluates approaches for partially or fully disabling the output of diagnostic data produced by Office.
I have started to have a look at my local installed helpers on macOS. These helpers are used as an interface for applications to perform privileged operations on the system. Thus, it is quite a nice attack surface to search for Local Privilege Escalations.
Forklift is an advanced dual pane file manager for macOS. It is well known under macOS power users.
As part of my investigation I identified vulnerabilities in Forklift allowing local privilege escalation.
Some time ago, we carried out an evaluation of the Digital Health Applications Ordinance (Digitale-Gesundheitsanwendungen-Verordnung, DiGAV) for the Federal Chamber of Psychotherapists in Germany (Bundespsychotherapeutenkammer, BPtK) focusing on the security of digital health applications, often referred to as apps on prescription.
The audit was intended to determine to which extent security guidelines, security objectives, and best practices are adhered to by the requirements formulated by the ordinance, thus enabling the foundations to securely operate digital health applications. The main subject of the examination is whether requirements, including procedural requirements defined in the ordinance are sufficient to ensure security of digital health applications. The examination has shown that the requirements can be seen as positive. However, in order to be able to make reliable statements about the IT security of digital healthcare applications, further details and mechanisms should be clarified within the ordinance, which I would like to present in the following.
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. Continue reading “OpenSIS Vulnerabilities”
The use of Internet of Things devices is continuously increasing: People buy devices, such as smart assistants, to make their lives more comfortable or fitness trackers to assess sports activities. According to the Pew Research Center [1], every fifth American wears a device to track their fitness. In Germany, the number increases likewise. The increasing number of fitness trackers in use can also be seen in criminal proceedings, as there exist more and more cases where these devices provide evidence.
Which useful evidential information fitness trackers collect and how to analyze them forensically was part of a paper that we presented at WACCO 2020 this year [2]. The goal was to develop an open source program to support investigators analyzing data that fitness trackers provide and to give a general approach on how to analyze fitness trackers.
Hardening guides for different systems that can be managed by Puppet are easy to find, but not the guides for hardening Puppet itself.
The enterprise software configuration management (SCM) tool Puppet is valued by many SysAdmins and DevOps, e.g. at Google, for scalable, continuous and secure deployment of application server configuration files across large heterogeneous system landscapes and increasingly also as “end-to-end” compliance solution.
Disclaimer:
This blog post does not present anything new about Puppet security, but aims to raise security awareness and summarize useful attack and audit techniques for an internal black and whitebox infrastructure assessment of a Puppet Enterprise landscape.
Most information in this post were collected during and based-on a time-limited graybox Puppet landscape assessment (Puppet Enterprise version 6.4.0, on RHEL7).
Hence, there is no claim for completeness and the post shall not be considered as a fully fledged Puppet hardening guide.