Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Hacking and Defending a Linux-Based Capture-the-Flag

February 6, 2018

  • Blog
  • Archive

Note: This blog complements a webinar I did in December 2017. Watch it here.

view on-demand webinar

One of my favorite ways to demonstrate the effectiveness of configuring Linux machines for stronger security is to look at an actual attack path. In my December 2017 webinar, we attacked the DonkeyDocker “boot2root” virtual machine (VM). (Footnote: Boot2root VMs serve as single-player capture-the-flag (CTF) exercises.). The vital parts of the attack path proceed like this:

  1. Exploit a PHPMailer vulnerability to add an attacker-supplied PHP page to the web server, containing a remote access trojan.
  2. Receive a connection from the remote access trojan with a Netcat listener.
  3. Escalate privilege from the web server user to a human user with su, guessing a password.
  4. Find an SSH private key and use it to “pivot” to a second system.
  5. Use Docker group membership to achieve root on the host system.

We can defeat each numbered step above with proactive hardening that doesn’t depend on the defender knowing what vulnerabilities his system possesses.

For a demonstration of how to defeat the first two steps, I encourage you to watch the webinar. Now, let’s examine how we can defeat the third and fourth steps.

In the third step of the attack path, we used the su (switch user) program to escalate privilege from our web server user, www-data, to a human user, smith. Smith’s password was easy to guess, but because this machine was a container without an SSH server, we had to use su. But why should the system owner let the www-data account use su in the first place? Our web server program has no operational need to run su. Frankly, only the system administrators / DevOps engineers should be able to “switch user.”

If we enforce this behavior, we break this attack path. This doesn’t require any kind of prescience – confining su to the administrative staff is a proactive best practice that was the default on some of the older Unix operating systems. Here’s how we do it:

  1. Choose a group to own the su program, often “wheel” or “admin.”
  2. Place any users who need to run su into the chosen group.
  3. Change the group ownership of the su program.
  4. Confine execution of the su program to this group.

In practice, this is how it would work:

usermod -a -G admin jay

chgrp admin /usr/bin/su

chmod 4750 /usr/bin/su

On a system where this best practice had been used, the www-data would not have been able to escalate privilege to smith using su.

Now, let’s look at step four of the attack path. The fourth is where we found an SSH private key and used it to pivot our attack to another system. There are actually a few different best practices that would have stymied this part of the attack.

  • Password-protect the SSH private key
  • Add multi-factor authentication to SSH
  • Keep SSH private keys off of servers
  • Don’t permit servers to SSH to other servers

While most of us would like to simply tell the owners of this system to make sure to use an encryption passphrase on their SSH private keys, I don’t believe that’s the best option. In our red team exercises and penetration tests at InGuardians, we often deploy keystroke loggers to capture these passphrases, along with any other password we can get our hands on. With that understanding, it seems clear that adding multi-factor authentication to SSH is the measure with the greatest chance of success. The other three measures described above are also useful, but having the right kind of multi-factor authentication can prevent a single keystroke logger from ruining your day. (Footnote: I’d advise you to use all four of the defense measures as defense-in-depth provides the best protection.)

You can add multi-factor authentication to a system cheaply or via commercial products. For a cheap measure, consider the Google PAM authentication module or a freemium service. For a somewhat more expensive measure, consider a tool like a hard token (RSA keys…) or a Yubikey. The goal is to pick a measure that makes a single set of keystroke-logged credentials insufficient to gain the same long-term access as the user. For more on this topic, watch the webinar!

Jay Beale

co-founder, COO and CTO, InGuardians

Jay Beale has created several defensive security tools, including Bastille Linux/UNIX and the CIS Linux Scoring Tool, both of which were used widely throughout industry and government. He has served as an invited speaker at many industry and government conferences, a columnist for Information Security Magazine, SecurityPortal and SecurityFocus, and a contributor to nine books, including those in his Open Source Security Series and the “Stealing the Network” series. He has led training classes on Linux Hardening and other topics at Black Hat, CanSecWest, RSA, and IDG conferences, as well as in private corporate training. Jay is a co-founder, Chief Operating Officer and CTO of the information security consulting company InGuardians.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Webcasts | February 09, 2021

Customer Webinar: Remote Support 21.1 Released!

Webcasts | February 24, 2021

Your PAM 2021 Blueprint: Securing Privileged Accounts for On-Premises and Cloud Assets

Whitepapers

Evolving Privileged Identity Management (PIM) In The 'Next Normal'

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.