The Hurricane Labs Foundry: Volume 9, The Quick, and the Exploited

Welcome to another edition Hurricane Labs Foundry! I’m Tony Robinson, one of the security operations analysts at Hurricane Labs. The goal of this series is to inform readers about current security news and innovations to keep you aware of the latest threats and technology. Additionally, this series discusses various aspects of Splunk deployment, as well as observations and projects from the Hurricane Labs SOC.

The stories presented here are mostly short digests with links to source material in order for readers to get the full scoop, and additional context as required.

Please Note: Tools, signatures, patches, resources, etc. that are linked to in this blog post are not the property of, and are in no way officially supported by, Hurricane Labs. Remember to do your due diligence and test before deploying any new tools, signatures, patches, or countermeasures!

CyberArk Password Vault Web Access Remote Code Execution

Recently, RedTeam Pentesting GmbH published a blog post regarding a RCE (Remote Code Execution) vulnerability discovered in CyberArk’s Password Vault Web Access application.

The Web Access app is a .NET application. The vulnerability is with the REST API that the Web Access application provides, specifically in how the application handles authorization. If the user of the application attempts to make an API call, their authentication token must be included in an HTTP authorization header, created by the “Logon” API method the application provides.

This authentication token is a Base64, serialized .NET object, and while that it and of itself is not a bad thing, the problem is that the integrity of the serialized data isn’t protected, or checked. This means that the Authorization header can be manipulated by an attacker to execute arbitrary commands via unsafe deserialization of an object the attacker can control, and the server/application does not perform valid integrity checking of.

Deserialization vulnerabilities have been around for a while, but were widely publicized around the end of 2015, early 2016. As the linked blogpost states, serialization is the process of converting application data to another format suitable for transportation (e.g. over the network), while deserialization is the process of converting this data back into a format the application can utilize. A lot of the initial research into deserialization vulnerabilities was centered around Java-based web applications and platforms, but has expanded to include .NET based applications as well. In fact, the vulnerability report references “ysoserial.net”, the .NET version of the “ysoserial” tool suite available on GitHub. The researchers used ysoserial.net to generate a serialized Base64 payload that, when specified as the HTTP Authorization header, would cause the system to execute the ping command.

CyberArk is aware of this vulnerability and has released new versions of the Password Vault Web Access application to remediate this vulnerability. Additionally CyberArk customers have been provided with a security bulletin in regard to the impact, and steps required to address this problem.

In addition to all of that, we here at Hurricane formulated a Splunk correlation search that – provided you are ingesting CyberArk web application logs – could help you identify potential exploit attempts:

Forensic Analysis of a Hacked WordPress Site

Every so often, on various social media sites I come across blog posts like this that are a walkthrough of a compromise or a given security event. Given the ubiquity of WordPress, I wanted to give this blog post some attention, as Glen Scott does a great job of going over the investigative process involved in investigating a compromise.

What I found most fascinating about the article is that, in addition to an analysis of the artifacts dropped by the attacker, we also got to see part of the attacker’s database infrastructure indicating that hundreds of other WordPress sites were compromised in a similar manner as the website the blog focuses on. In addition to the forensic write-up, near the end of the blog post, the author includes links to several other resources for recovering a compromised WordPress site, as well as resources and recommendations for hardening your own WordPress installations.

Filtering Out the Top 1 million Domains from Corporate Network Traffic

NVISO Labs has posted an article that details their research into obtaining a list of the top 1 million domains, and applying those domains as a filter to your network traffic analysis. The result of this can be a way of reducing noise and making it easier to perform tasks related to threat hunting. Being able to filter out the most commonly queried external domains from, say, a Passive DNS dataset, allows security analysts to focus on just the uncommon or unusual DNS queries which could lead to faster turnaround for finding unknown bad things trying to reach out of your network amongst all the noise.

NVISO also did research where they only filtered out part of the top 1 million domains (e.g. 1000, 2000, 100,000, etc.) to determine a “sweet spot” between the number of domains filtered, versus the amount of seemingly benign traffic filtered. Per the research, filtering the top 100,000 domains out of the top 1 million resulted in a 49% reduction in traffic analysis, resulting in diminishing returns after that point.

NVISO makes it a point to note that several of the top 1 million domains are expired and could possibly be re-registered by bad guys, resulting in bad traffic being missed. I’d also like to add a word of caution that filtering these domains could leave your enterprise network susceptible to advance techniques, such as domain fronting, in which actors will specify the URL of one benign website or service, but will specify an HTTP host header that points to another service or system that they actually want the traffic to go to. Some CDNs (Content Delivery Networks) and websites will happily forward the traffic on to the domain specified in the host header. Thus, the DNS traffic and HTTP GET request are for benign domains, but the response is coming back from the actual target domain in the HTTP host header.

Race Condition in the Linux Beep Command Allows for Privilege Escalation

A new vulnerability for Linux users was discovered, labeled “holeybeep”. The vulnerability exploits a race condition in the beep application, in combination with the fact that the beep application is a SUID root binary. So, that harmless application that causes your PC’s internal speaker to emit a simple “beep” tone? Yeah, that application requires root permissions to do that, and can be exploited to give local attackers root access to your system.

Some Things You Might Not Know About Tinder

In an article written by researcher @adezero, also known as @socialhax, she takes the time to write some interesting things about the Tinder dating app that you may or may not be aware of. Normally I shy away from talking about mobile applications as a whole, because they are by and far humongous tar pits when it comes to data privacy… But with the recent uproar surrounding Facebook and the Cambridge Analytica data leak, this article should serve as a reminder that the old adages: “No such thing as a free lunch”, and the ever-popular “If you are not the customer, then you are the product” still ring true.