Research

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.

Privilege Escalation in IBM Notes Diagnostics #3-5

This is the fourth 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 IBM Notes Smart Update Service

This is the third 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 IBM Notes Diagnostics #2

This is the second 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 this blog post I will 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 IBM Notes Diagnostics #1

This is the first 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 will be a bit verbose and give 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 setting 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.