The last couple of days there has been some fuzz about the HP audio key logger as disclosed by modzero in their blog post and the detailed advisory that they released. The following sentence in their advisory peeked my interest:
This type of debugging turns the audio driver effectively into a keylogging spyware.
With all the hyped ‘repurposing’ of tools that is going on lately I wondered how difficult it actually is to turn this into an intended piece of malware. The reason I find this interesting is because according to different sources it’s legitimate software which has been code-signed correctly and has not been classified as malware by all anti-virus solutions, yet.
The current detection signatures are also pretty weak since they deem it mostly ‘riskware’ or ‘potentially unwanted application (PUA)’. This could have the side effect that users or administrators might just dismiss any warnings of signs of an attacker abusing the HP audio key logger for malicious purposes.
For red team purposes this is still a nice addition, since it pushes the person analysing this potential incident to really understand what is going on and figuring out that legitimate software is being abused for malicious purposes. Specially since the binary will not be modified and thus the code-signing remains valid (until the certificate is revoked).
Let’s dive into the technical details on the path / approach I followed on repurposing this piece of legitimate software for nefarious red team purposes ;)
Continue reading “Repurposing the HP audio key logger”
So this is a *really* old blog post that I wrote a while back when I discovered, or at least so I believed, an XXE bug in the VMware vSphere client. I reported this to the VMware security team but they were not able to reproduce the part where you would use a UNC path to try and steal the credentials of an user. I then got busy and never continued to investigate why they were not able to reproduce it. Since the vSphere client is being replaced by a web client I decided it couldn’t hurt to release this old post, also the likely hood of this being exploited is pretty low.
Curiosity (from Latincuriosus “careful, diligent, curious,” akin to cura “care”) is a quality related to inquisitive thinking such as exploration, investigation, and learning, evident by observation in human and many animal species. (Wikipedia)
As always a driving force behind many discoveries, as well as the recent bug I found in the VMware vSphere client (vvc). Not a very interesting bug, yet a fun journey to approach things from a different perspective. After my last post about a portable virtual lab I wondered what the vvc used as a protocol to communicate with the esxi server and if it could contain any bugs. So this time instead of getting out ollydbg I decided to go for a more high-level approach. Let’s see how I poked around and found the XML External Entity (XXE) (pdf) vulnerability in the vvc.
I first looked in the directory of vvc, just to know the type of files that resided there, here is a screenshot:
Logically the file that drew my attention was the config file of which the following settings also seemed like they would come in handy:
Seems like if we want to tinker with the connection a higher time-out would give us more time and a higher verbosity level of logging could help us during the poking around. Enough looking around at this point let’s get more active.
Continue reading “[old] VMware vSphere client XML External Entity attack”