With this blog post I am pleased to announce the publication of a new ERNW White Paper [1]. The paper is about severe vulnerabilities in an insulin pump we assessed during project ManiMed and we are proud to publish this subset of the results today.
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.
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.
Last week I attended ACM WiSec. Of course, only virtually. The first virtual conference I attended. Coincidentally, it was also the first conference I presented at. While the experience was quite different from a “real” conference, the organizers did a great job to make the experience as good as possible with, for example, a mattermost instance to interact with other conference participants.
In the following, I will list a few talks and papers that I either found very interesting or that generally stood out to me:
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. Continue reading “QEMU, Unicorn, Zelos, and AFL”
From the end of 2019 on, we reported two critical vulnerabilities in the Ivanti DSM Suite to the vendor. The following CVE IDs were assigned to the issues (but note that they have a status of RESERVED, i.e. titles and descriptions may change in the future):
CVE-2020-12441: Denial-of-Service (DoS) in Ivanti Service Manager HEAT Remote Control 7.4
CVE-2020-13793: Unsafe storage of AD credentials in Ivanti DSM netinst 5.1
So there was a pandemic, the whole world was under lockdown, and I got a bit depressed.
I needed something new in my life, so I decided to take my favorite dog out for a walk in the ATT&CK jungle to check out the newly added sub-techniques…
Digital networking is already widespread in many areas of life. In the healthcare industry, a clear trend towards networked devices is noticeable, so that the number of high-tech medical devices in hospitals is steadily increasing.
In this blog post, we want to elucidate a vulnerability we identified during the security assessment of a patient monitor. The device sends HL7 v2.x messages, such as observation results to HL7 v2.x capable electronic medical record (EMR) systems. A user with malicious intent can tamper these messages. As HL7 v2.x is a common medical communication standard, we also want to present how this kind of vulnerability may be mitigated. The assessment was part of the BSI project ManiMed, which we would like to present in the following section.