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:
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.
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.
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.
Years ago, Java could be used on websites trough applets. To make these applets
secure and not let them access files or do other dangerous stuff, Java
introduced the SecurityManager. Before some action was performed, the
SecurityManager was asked if the code is privileged to perform this action.
However, since the SecurityManager lives in the same running program and can be
accessed via System.getSecurityManager(), there
existed some ways to remove it.
In June 2020 we reported three vulnerabilities in Nagios XI 5.7.1 to the
vendor.
The following CVE IDs were assigned to the issues :
CVE-2020-15901: Command Injection in Nagios XI web interface (RCE)
CVE-2020-15902: Cross Site Scripting (XSS)
CVE-2020-15903: Reserved, details will be given on vendor fix
CVE-2020-15901 and CVE-2020-15902 have meanwhile been fixed in version 5.7.2
according to the changelog on the Nagios website
(https://www.nagios.com/downloads/nagios-xi/change-log/). CVE-2020-15903 is
currently being worked on by the vendor and will probably be fixed in the near
future.
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.