Privilege Escalation, Persistence & Covering Your Tracks

Linux

Terminal Learning Objectives/Learning Domains

Action:
Explain how to perform privilege escalation and maintain persistence on a Linux OS
Condition:
In a training environment, with appropriate graphical training aids, various learning constructs, and peer and instructor feedback
Standard:
Students will be able to explain Linux Privilege Escalation and persistence methodology

Learning Domains/Level of Learning:

Congnitive:
Knowledge, Comprehension
Affective:
Receiving, Responding, Valuing

Army General Learning Outcomes:
7,8,14

Safety Requirements:
No major considerations
Risk Assessment Level:
LOW
Environmental Considerations:
NONE
Evaluation:
Check on learning questions

Rationale

Privilege escalation and maintaining persistence are among the many post-exploitation skills and tasks that attackers must grasp. Attackers and defenders need to understand how privilege escalation can occur and how persistence can be maintained on a system. This understanding allows attackers to move freely through a network, and allows defenders to prevent privilege escalation, detect attacker movement, and detect/prevent attacker persistence mechanisms.

Objectives

Establish and maintain Linux persistence by:


  • Adding or hijacking a user account

  • Implementing boot process persistence

  • Adding or modifying a CRON job

  • Adding a kernel module (with a backdoor)

  • Additional methods outside the scope of the SG

Privilege Escalation

Discuss

  • What is privilege escalation?

  • What privs do I want, and why?

  • What are some considerations of privilege escalation?

  • If I obtained privs as user "bob," then I can obtain privs for user "jane," is that escalation?

Enumerating For Privilege Escalation

  • What are the techniques and processes?

    • Is there any particular order?

    • Is there anything else you should be doing while on the box?

Physical Access Discussion/Demonstration

SUDO

  • What is sudo?

  • Why should you consider it for privilege escalation?

  • What commands should you run?

SUDO Gotchas!

  • Commands that can access the contents of other files

  • Commands that download files

  • Commands that execute other commands (i.e. editors)

  • Dangerous commands


REFERENCES:

SUDO Demonstration

SUID/SGID

  • What is SUID/SGID?

  • Why should you consider it for privilege escalation?

  • What commands should you run?

Capabilities

  • What are capabilities?

  • Why should you consider it for privilege escalation?

  • What commands should you run?

SUID/SGID Demonstration

Insecure Permissions

  • CRON

  • World-Writable Files and Directories

  • Dot '.' in PATH

CRON

  • What is CRON?

  • Why should you consider it for privilege escalation?

  • What commands should you run?

World-Writable Files and Folders

  • Why should you consider it for privilege escalation?

  • What commands should you run?

Dot '.' in PATH

  • Why should you consider it for privilege escalation?

  • What commands should you run?

World-Writable Files and Folders/Dot '.' in the PATH Demonstration

Vulnerable Software and Services

  • Why should you consider it for privilege escalation?

  • What commands should you run?

Unpatched Kernel Vulnerabilities

  • Why should you consider it for privilege escalation?

  • What commands should you run?

Persistence

Discuss

  • What is persistence?

  • What is the purpose of persistence?

  • What are some considerations of obtaining or utilizing persistence?

  • Does persistence mean I have immediate access to the target?

Adding or Hijacking a User Account

  • Adding vs hijacking a user account

  • User account considerations?

  • How should you access it?

User Account Discussion/Demo

Boot Process Persistence

  • Where and how do you implement?

  • Why should you consider it for persistence?

  • How should you access it?

Boot Process Persistence Demo

Cron Job

  • System vs user CRON

  • Why should you consider it for persistence?

  • How should you access it?

CRON Persistence Demo

Kernel Module Backdoors

  • Why should you consider it for persistence?

  • How should you access it?

Kernel Module Persistence Demo

Discussing Other Methods

Covering Your Tracks

Objectives

  • Familiarization with OS auditing and logging

  • Perform log cleaning and blending in

  • Identify artifacts

Plan

  • Prior Initial Access? After Initial Access? Before Exit? (Know the system!)

    • What will happen if I do X (What logging?)

    • Checks (Where are things?)

    • Hide (File locations, names, times)

  • When do you start covering your tracks?

Artifacts

What are they?

System usage

  • Where to work from on the remote system? Why?

  • Are system resources important?

NIX-ism

  • First thing: unset HISTFILE

  • Need to be aware of of init system in use

    • SystemV, upstart, SystemD, to name a few

    • Determines what commands to use and logging structure

Ways To Figure Out Init Type

ls -latr /proc/1/exe
stat /sbin/init
man init
init --version
ps 1

Auditing SystemV

ausearch: Pulls from audit.log

ausearch -p 22
ausearch -m USER_LOGIN -sv no
ausearch -ua edwards -ts yesterday -te now -i

SystemD

Utilzes journalctl

journalctl _TRANSPORT=audit
journalctl _TRANSPORT=audit | grep 603

Logs for Covering Tracks

Logs typically housed in /var/log & useful logs:


auth.log/secure

Logins/authentications

lastlog

Each users' last successful login time

btmp

Bad login attempts

sulog

Usage of SU command

utmp

Currently logged in users (W command)

wtmp

Permanent record on user on/off

Working With Logs

file /var/log/wtmp
find /var/log -type f -mmin -10 2> /dev/null
journalctl -f -u ssh
journalctl -q SYSLOG_FACILITY=10 SYSLOG_FACILITY=4

Reading Files

cat /var/log/auth.log | egrep -v "opened|closed"
awk '/opened/' /var/log/auth.log
last OR lastb OR lastlog
strings OR dd            # for data files
more /var/log/syslog
head/tail

Control your output with pipes | and more

Cleaning The Logs

  • Before we start cleaning, save the INODE!

    • Affect on the inode of using mv VS cp VS cat

  • Know what we are removing (Entry times? IP? Whole file? Etc.)

Cleaning The Logs (Basic)

Get rid of it

rm -rf /var/log/...

Clear It

cat /dev/null > /var/log/...
echo > /var/log/...

Cleaning The Logs (Precise)

Always work off a backup!


GREP (Remove)
egrep -v '10:49*| 15:15:15' auth.log > auth.log2; cat auth.log2 > auth.log; rm auth.log2


SED (Replace)
cat auth.log > auth.log2; sed -i 's/10.16.10.93/136.132.1.1/g' auth.log2; cat auth.log2 > auth.log

Timestomp (Nix)

  • Access: updated when opened or used (grep, ls, cat, etc)

  • Modify: update content of file or saved

  • Change: file attribute change, file modified, moved, owner, permission

Timestomp (Nix)

Easy with Nix vs Windows (Native change of Access & Modify times)

touch -c -t 201603051015 1.txt   # Explicit
touch -r 3.txt 1.txt    # Reference


Changing the change time requires changing the system time than touch the file. Could cause serious issues!

Remote Logging

Good? Bad? Both?

Remote Logging

  • Check the config!

    • Identify server being shipped to!

    • Identify which logs are being shipped

  • Rsyslog? Need to be thorough!

    • New version references multiple files for rules

Rsyslog

  • Newer Rsyslog references /etc/rsyslog.d/* for settings/rules

  • Older version only uses /etc/rsyslog.conf

  • Find out
    grep "IncludeConfig" /etc/rsyslog.conf

Reading Rsyslog

  • Utilizes severity (priority) and facility levels

  • Rules filter out, and can use keyword or number

<facility>.<priority>

Rsyslog Examples

kern.*                                                # All kernel messages, all severities
mail.crit
cron.!info,!debug
*.*  @192.168.10.254:514                                                    # Old format
*.* action(type="omfwd" target="192.168.10.254" port="514" protocol="udp")   # New format
#mail.*

Questions?