Exposed & Exploited

There is zero room for pride in cybersecurity.

But don’t take our word for it:

Brute force. RDP. Not a CVE. Not a zero day.

And your zero trust framework falls apart when they get in and create their own trust.

These are external infrastructure attacks, and they are lethal. Even worse, they are reliable.

How do we know? We’ve executed more pentests than three of the top pentesting consultant firms over the last year, and we know what the world’s worst ransomware organizations know: external infrastructure is an easy attack vector.

The good news is remediation and mitigation are simple. You don’t need a specialized security team or radical policy to implement; you can find, fix, and verify these attack vectors now.

What follows are the top external infrastructure attack vectors we’ve exposed and exploited over the last year…all with path and proof. Buckle up.

1. Weak web app credentials

Weak password policies are no different than perfect password policies that are unenforced or never tested, as both ensure brute force attacks are extraordinarily simple and effective. Even worse is when our people create simple company name-based passwords and reuse them. Not only do we make an attacker’s job easier, but we also make it incredibly difficult to detect. Here’s how this attack plays out:

1. Search for a target company’s publicly accessible servers on a thirdparty URL search.
2. Using LinkedIn, create probable usernames for employees: i.e., “CompanyName123!”
3. Spray potential usernames and see what sticks.

Using LinkedIn, we constructed 400 probable usernames for company employees. We then sprayed common passwords such as “[companyname]1234” and “[companyname]123!” against https://jenkins.[companyTLD].com

And it worked. For two users, we were able to access Jenkins with readonly permissions. Notably, we were able to login as other users as well, but they did not have any Jenkins permissions.

We could stop here, getting the point across that default credentials on your public-facing web applications are dangerous; but, we’d like to drive this point home by showing just how much deeper this rabbit hole can go.

With read-only access, we inspected various build jobs and found several instances where credentials were being exposed as part of the console output. As an example, the following console output shows a token for the company’s Docker registry.

We then used this token to successfully log in to access the registry:

The /asynchPeople endpoint on a Jenkins server shows all users with access to Jenkins. With read-only access to Jenkins, we enumerated all Jenkins users and then repeated the brute force login/password spray from the first step. We found one user with Jenkins admin access and weak credentials.

With admin access to Jenkins, we accessed the Jenkins Script Console located at /script. This is an incredibly powerful tool intended for advanced troubleshooting that can be abused in various ways.

First, we dumped over 50 credentials in plaintext stored within the Jenkins server. These credentials included AWS keys, SSH private keys, and various usernames and passwords. An attacker could use these credentials against other company assets and to pivot internally within a company’s network.

We found that their Amazon Web Services (AWS) cloud network was directly linked to the on-prem network. This means an attacker could easily move into the on-prem environment by implanting a shell on this Jenkins server. From this script console, we were able to see the network monitoring tool server IP address over HTTP using curl from the Jenkins node… and lo and behold, this server was within the same /24 subnet as the main domain controllers.

Using the Jenkins Script Console, we also dumped the AWS credentials (access key, secret key, and token) being used by the Jenkins EC2 host. We found that these AWS credentials had a large set of permissions available to them, including access to critical services such as S3, EC2, and RDS.

Using these credentials, we dumped a list of S3 buckets in the company account, EC2 instance metadata, and Lambda metadata.

And while we’re on the subject of credentials…

2. Default web app credentials

Default credentials are even more dangerous, making brute force attacks even more simple and effective. These out-of-the-box defaults give attackers a vector to exploit virtually undetected because they appear authenticated. And what if your public-facing and integrated web apps are using default credentials?

In one pentest we gained access using default credentials to the JasperSoft reporting tool hosted at practice-jasper.[companyname].com, demo-jasper.[companyname].com and training-jasper.[companyname]. com. The default credentials are jasperadmin/jasperadmin.

Admin access to JasperSoft is equivalent to remote code execution. An article describing the process is here: https://foxglovesecurity.com/2016/10/14/hackingjasperreports-the-hidden-shell-feature/

We also found this JasperSoft instance appears to be linked to an active production database, whose credentials could be obtained by achieving remote code execution (RCE) on the JasperSoft node. An attacker could then access the database backed being used by this JasperSoft server or could readily use the JasperSoft tool to dump data from the database.

3. Credentials left in Github repos

Open source and third-party applications offer incredible capabilities for your developments teams to build, test, and deploy code fast. We want to outpace competitors so we can get our WHITEPAPER For example, again, we’re searching for our target company’s name in public repos. We found a public Github repo owned by the company and discovered products to market first, and we want to outpace attackers who learn about vulnerabilities the same moment we do.

Regretfully, development teams will often create shortcuts to remove perceived unnecessary security pain, which restricts their speed. Sometimes, that means embedding credentials with escalated privileges.

For example, again, we’re searching for our target company’s name in public repos. We found a public Github repo owned by the company and discovered products to market first, and we want to outpace attackers who learn about vulnerabilities the same moment we do.

A quick search found a markup .yml file inside a tarbell Airflow tgz, and we found a cleartext password to a production system. The password was used to access the Airflow server with administrative privileges.

An attacker with admin privileges to Airflow had access to a lot of sensitive data and could significantly disrupt operations.

We then used those credentials to log into Airflow as an administrative user – because verification and proof is invaluable – and provided the company with the screenshots and locations of every step on the attack path.

4. Critical CVEs leading to remote code execution

Attackers are always looking for sensitive information, especially company-sensitive information such as employee records, financials, intellectual property, network architectures, source code, and proprietary information. The absolute last thing you want to do is make it easy for an attacker to access such information. However, when we do not remediate known vulnerabilities on our publicfacing websites, that’s exactly what we do.

While we’ve discovered this multiple times, in one case the attack path was not limited to sensitive data at the edge but led all the way to domain admin rights.

In this pentest, we found that one of the company websites was running Ruby on Rails version 3.0.17 in the HTTP response headers:

This version of Ruby on Rails is known to be vulnerable to CVE-2013-0156, an object deserialization vulnerability in Ruby on Rails.

Just to confirm what we were thinking, we ran whoami and ifconfig commands which showed that we were running commands as the user webapp and that the internal IP address was the same as the production server.

Knowing this, we ran the cat /etc/passwd command… and then – in cleartext – we could see local credentials.

Going further, we discovered the password for a domain user in the ldap.yml config file, and now using this password we were able to authenticate to Active Directory as the domain user.

Don’t forget, we were looking for sensitive information. We found a local database.yml file and discovered credentials for a local postgres database.

Using these credentials, we were able to query the local database, where we find partners, customers, newsletters, and target information that ransomware attackers can’t wait to encrypt and threaten a company with.

This is a critical finding that enables remote unauthenticated attackers to gain a foothold into the internal network. From here, an attacker has many paths open to them to fully compromise the AWS and on-prem networks and steal the data that can be accessed within. Access to the domain user and the local Postgres database are the tip of the iceberg in terms of what’s possible.

5. RDP/SMB exposed on Internet + cred spray

(RDP is top malware/ransomware vector)

We’ve seen it repeatedly, where port 3389 exposed on a webserver or third-party virtual machine, often requiring simple – if any – authentication, and once compromised, allows an attacker remote and persistent access to your infrastructure, and is often the first stage in ransomware attacks.

Conclusion

Understanding the attack paths an attacker would exploit to hold your business and brand at risk is key; hence, understanding your public-facing infrastructure is key towards realizing what your attack surface truly looks like to an attacker.

While we explored a few attack paths here, there are many more exposed and exploited daily. We’ll dig into these in more detail another time. Until then, our recommendations to protect yourself are:

• Verify your full external footprint.
• Don’t expose anything that doesn’t need to be public.
  • Verify RDP connections are not allowed over open internet
• Verify your credential policy is enforced.
  • Require authorization with MFA for all logins.
  • If MFA isn’t possible, use strong passwords, but beware that strong passwords can still get exposed.
• Patch: Burn down debt on critical CVEs from the past and keep up to date with zero days.
• Implement a configuration management process.
• Protect staging and dev environments, too.
• Upfront security design and testing for custom web apps.
• Verify applications and integrations that should have been removed have been removed.

Being exposed sucks. Just ask your credentials… and sensitive data.