Tech Blog
Improsec identified the vulnerabilities during a customer engagement. Each vulnerability was validated in a simulated AD Lab afterwards. The vulnerabilities were disclosed to the vendor, IXP Data, on November 11 of 2019. IXP Data releases EasyInstall version 6.3.101 which patches all six vulnerabilities on November 15 of 2019.
In this short blog post we will have a quick look at the development of GPU performance since Improsec started four years ago until today. The sad side of this story is, that password usage is still an essential security risk. Human passwords are not three times better today compared to back when Improsec started (we know because we crack passwords all the time). However, multi-factor authentication and password managers are getting more and more common, so there’s some light ahead :)
TIBER stands for Threat Intelligence-Based Ethical Red Teaming.
In a nutshell, what differentiates a TIBER-DK test from a typical Red Team (RT) test is that the RT has to make it seem as if attacks are performed by one or more specific threat actors.
Imagine you as a chef are used to cooking Italian food, and suddenly are tasked with cooking French food, to make it seem as if there is a French chef in the kitchen. It's still cooking. Many aspects of both are the same, but yet different.
Kerberos delegation has been in the spotlight for some time now and the risks behind it have been outlined in quite a few blogs and conference presentations - I particularly recommend reading https://adsecurity.org/?p=1667 and https://www.harmj0y.net/blog/redteaming/another-word-on-delegation/. For some time, it was my incorrect understanding that unconstrained delegation is a massive problem while constrained/resource-based is less destructive. That is however not the case, and the exploitation that is to follow absolutely blew my mind the first time I saw it in "action".
When a service account is set for "Use any authentication protocol" delegation, it means that the service account is allowed to delegate without being required to prove that a user authenticated to it! In normal words, just saying "I shall pass because I am the administrator, trust me!" opens the door with no questions asked and no one verifying that you are in fact the administrator. Sounds crazy, right? Let's have a walk through.
With claims that WordPress runs on 33% of all websites, WordPress has received a fair amount of security scrutiny over the years.
Disclaimer: This blog post is not a complete guide on deploying Privileged Access Workstations (PAWs) that work in any environment. The information contained here defines the concept behind Privileged Access Workstations and presents a working generic implementation. Complete implementation requires deep knowledge of the specific infrastructure and definition of all the tasks to ensure that any other activity is denied execution on the machine, which reduces the likelihood of a potential compromise of it, significantly.
Securing windows environments in a way that prevents lateral movement and/or escalation of privileges has become an incredibly difficult task. The research and tools created in the past 2-3 years have been simply amazing, which helped to identify new attacks and vulnerabilities, while lowering the sophistication required to exploit them. The easiest way to ensure that your environment is built in a secure manner, is to rebuild it from scratch with a security architect behind the design. As Microsoft states, one may never trust Active Directory, if it has been compromised, unless it is possible to return to a known good state.
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.
Application whitelisting is one of those actions on an organization's security roadmaps, which either never happens or is adapted to fit the current environment rather than having it implemented to its full extent. Although far from perfect, with a large number of bypasses for its whitelisting capabilities (described in the Github repository here), AppLocker is still a great, free* tool that introduces resilience in the environment. Many of the bypasses rely on abusing Microsoft signed executables, as they are whitelisted by default and have the capability to launch other executables. In the previously linked Github repository, the author has made an effort to provide AppLocker rules to prevent the bypasses, however, many of these are likely to break things in a fully-functional real-world environment with "legacy" systems.
I encountered what is known as Routed SQL Injection a couple of times but it was never required to exploit the vulnerability to the full extent. Recently, I discovered an online challenge on the topic and decided to look at it in depth. An explanation of the vulnerability with a vulnerability code which is described in the beginning this post, can be found here.
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.
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.
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.
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.
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
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.
