We found a vulnerability in EXEMSI MSI Wrapper, which affected multiple third-party software vendors.
Privilege escalation vulnerability in Lenovo System Update
System Update is an application for keeping drivers, firmwares and software packages up-to-date on Lenovo workstations or laptops. The application often comes preloaded on Lenovo systems.
Like in my previously disclosed vulnerabilities for Intel Driver & Support Assistant and Splashtop Streamer, the process of updating software and firmware can, if not implemented securely, leave a system vulnerable for privilege escalation.
Privilege Escalation vulnerability in Splashtop Streamer
This blog post highlights bugs found in installed software while doing vulnerability research. The process for this publication is aligned with the Improsec Responsible Disclosure Policy.
Splashtop Streamer is a remote desktop application that allows users to share their desktop and remotely control workstations. The affected component is the Splashtop Updater that is bundled with Splashtop Streamer, as well as certain other Splashtop products.
Mitigate the risk of insecure passwords - we give you Get-bADpasswords
A common approach to gaining access into an Active Directory environment is to crack the password of a specific target user through means of brute-force or dictionary attacks. Built-in password policies for Active Directory can reduce the success rate of brute-force or dictionary attacks and will often prohibit access to accounts with too many failed login attempts.
Privilege escalation in IBM Notes Diagnostics #6
This is the fifth blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.
In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.
Client side code execution in IBM Notes
This is the sixth blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.
In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.
Privilege Escalation in Heimdal #2
This blog post highlights bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.
In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.
Privilege Escalation in Heimdal #1
This blog post highlights bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.
In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.
The enterprise-ready workaround I would have expected from IBM
When IBM promised to release a workaround for the vulnerability we found in their product, I truly expected such a widely respected company to release an enterprise-ready workaround, and not just a manual approach to set registry permissions in the GUI.
How we found a vulnerability in IBM's backup product - the workaround and a bit about the Responsible Disclosure process
A few months back, my good friend Flemming Riis and I found a fundamental security vulnerability in the IBM Tivoli Storage Manager (TSM) client, while researching IBM TSM’s handling of authentication ("Node ID" and "Node Password") and unsafe implementations of TSM, which we covered in a few blogposts Backdoors and data compromise via Backup Systems (in danish only) and Protecting your secrets.
We couldn't believe our own eyes when we, in very little time, found a pretty important – and incredibly trivial – security vulnerability in the TSM product.
We then initiated a Responsible Disclosure process with the IBM Product Security Incident Response Team (PSIRT), which I will describe further below, as it illustrates how important it is for researchers to set requirements and insist on deadlines being met.