Adversary versus target; all organizations participate in this daily cat-and-mouse. Organizations initially fought this battle on the technology front. Miss something? Find another new technology to address the gap. Over time, technology delivered interesting intel, but malicious activity still slipped through. Organizations then went on the hunt to find the “right” person with the “right” skill. And this cycle continues unabated – tech, people, tech, people, tech, people, etc.
Are things better? Undeniably. Can they be better still? Without question. But as long as the tech/people cycle continues, most organizations will never reach their cybersecurity goals because the goal will always be just out of reach by one person or one technology. To illustrate this, we’ll use the recent Exorcist 2.0 ransomware.
Unicode-related vulnerabilities have seen an increase in momentum in the past year. Last year, a Black Hat presentation by Jonathan Birch detailed how character normalization NFC/NFKC can lead to glitches in URL and host manipulation. Recently, two vulnerabilities were found in password reset functionality. The two affected applications were Django and Github. In the previous blog post, we have presented API transforming code points with potential side effects. In this post, we present one of our findings: a vulnerability affecting Oracle JDK and Open JDK host verification in the TLS communication. We are also including details from a similar weakness in Apache HTTP client.
In this post we outline the release of PyRDP version 1.0 and highlight the newly added features and improvements made to the tool since 0.4.1. PyRDP is a Remote Desktop Protocol (RDP) stateful proxy that can intercept and tamper with sessions for offensive security engagements and malware research.
This is the second blog post in a series discussing attacks leveraging Windows Server Update Services (WSUS).
After having revived the classic 2015 WSUS attack in part 1 of the series by creating a tool, PyWSUS, that works on Windows 10, we started to wonder if the module could be used for other purposes.
We often see deployments using WSUS where users can set the local proxy for their session. If the WSUSpect-proxy module is nothing more than a MITM proxy that modifies some parts of the traffic and we also have the power to proxy our local traffic, we therefore have the power to run WSUSpect-proxy locally to run code as System on our asset.
At GoSecure, we work hard to illustrate the impact of our pentest findings on our clients’ security posture. In the past few years, we found numerous organizations with vulnerable Windows Server Update Services (WSUS) deployments. However, no tool (reliable enough to use during engagements) was available to show to clients the risks associated with this critical vulnerability. For these reasons, in the next series of blog posts, we will describe the vulnerability, explore its attack vectors and release new tools to weaponize the vulnerability, and subsequently, demonstrate its impact.