Often during the penetration test engagement the security analyst faces the problem of identifying privilege escalation attack vectors on tested Linux machine(s). One of viable attack vectors is using publicly known Linux exploit to gain
rootprivileges on tested machine. Of course in order to do that the analyst needs to identify the right PoC exploit, make sure that his target is affected by the associated vulnerability and finally modify the exploit to suit his target. The
linux-exploit-suggester.shtool is designed to help with these activities.
The tool is meant to assist the security analyst in his testing for privilege escalation opportunities on Linux machine, it provides following features:
"Remote" mode (--kernel or --uname switches)
In this mode the analyst simply provides kernel version (
uname -acommand output (
--unameswitch) and receives list of candidate exploits for a given kernel version.
Using this mode one can also check for candidate user space exploits (with
--pkglist-fileswitch) if he has access to installed packages listing (output of
dpkg -l/rpm -qacommands) of examined system.
"Direct" mode (default run)
The basic idea behind this mode is the same as previously but additionally in an effort to produce more relevant list of candidate exploits, the tool also performs series of additional checks (like: kernel build settings aka CONFIG_*, sysctl entries and other custom checks) to rule out exploits that for sure won't be applicable due to OS customization. So for example for 'af_packet' exploit which requirements looks like this:
the script (in addition to checking kernel version) will check if target kernel was built with
CONFIG_USER_NSand if sysctl entry
kernel.unprivileged_userns_cloneis enabled. Optionally those additional checks can by skipped by running with
--skip-more-checkscommand line switch.
By default tool also checks for applicable user space exploits when distribution is one of
Debian, Ubuntu, RHEL/CentOS/Fedora. To skip user space exploits checks one can run with
"CVE list" mode (--cvelist-file switch)
In this mode the analyst already posesses partial/full list of CVEs that affects his target kernel and wants to verify if there are any publicly known exploits against this CVEs. Of course efectivness of this mode highly depends on completness of provided CVE list. Such list is usually constructed by manual study and examination of distribution's Changelog for the given kernel version. Alternatively for most popular distros Oracle's Ksplice Inspector could be used to speed up this proccess. For example following oneliner worked quite fine for me:
WARNING. By default in addition to comparing CVE IDs, this mode also performs additional checks to rule out exploits that won't be applicable due to OS customization (kernel build settings aka CONFIG_*, sysctl entries and other custom settings). So for the best possible results one should run it directly on tested machine or alternatively use
$ (uname -s; uname -m; uname -r; uname -v) | curl -s https://api-ksplice.oracle.com/api/1/update-list/ -L -H "Accept: text/text" --data-binary @- | grep CVE | tr ' ' '\n' | grep -o -E 'CVE-[0-9]+-[0-9]+' | sort -r -n | uniq
--skip-more-checkscommand line switch if running on the target is not possible/not desired.
"Check security" mode (--checksec switch)
WARNING. This mode is in beta currently.
This mode is meant to be a modern continuation of checksec.sh's
In this mode
linux-exploit-suggester.shenumerates target system for various kernel/hardware security features (KASLR, SMEP, etc.) and settings. It checks if given protection mechanism is available (builtin into the kernel):
[ Available ]and (if applicable) it check if it can be disabled/enabled without recompiling the kernel (via
sysctlentry or other means):
[ Enabled/Disabled ]or shows
[ N/A]if disabling/enabling is not possible/not supported.
Tips, limitations, caveats
- Remember that this script is only meant to assist the analyst in his auditing activities. It won't do the all work for him!
- That's the analyst job to determine whether given target at hand isn't patched against generated list of candidate exploits (the script doesn't look at distro patchlevel so obviously it won't do that for you)
- In addition to manual inspection Oracle's Ksplice Inspector could come handy with determining the previous one
- Selected exploit almost certainly will need some customization to suit your target (at minimum: correct commit_creds/prepare_kernel_cred pointers) so knowledge about kernel exploitation techniques is required
Default run on target machine (kernel version, packages versions and additional checks as described in "Overview" paragraph are performed to give the list of possible exploits:
As previously but only userspace exploits are checked:
Check if exploit(s) for given list of CVE IDs are available:
$ ./linux-exploit-suggester.sh --userspace-only
Generate list of CVEs for the target kernel and check if exploit(s) for it exists (also performs additional checks):
$ ./linux-exploit-suggester.sh --cvelist-file <cve-listing-file> --skip-more-checks
List available hardware/kernel security mechanisms for target machine:
$ (uname -s; uname -m; uname -r; uname -v) | curl -s https://api-ksplice.oracle.com/api/1/update-list/ -L -H "Accept: text/text" --data-binary @- | grep CVE | tr ' ' '\n' | grep -o -E 'CVE-[0-9]+-[0-9]+' | sort -r -n | uniq > <cve-listing-file>
$ ./linux-exploit-suggester.sh --cvelist-file <cve-listing-file>
$ ./linux-exploit-suggester.sh --checksec
-koption is handy if one wants to quickly examine which exploits could be potentially applicable for given kernel version (this is also compatibility mode with Linux_Exploit_Suggester):
$ ./linux-exploit-suggester.sh -k 3.1
--unameone provides slightly more information (
uname -aoutput from target machine) to
linux-exploit-suggester.shand receives slightly specific list of possible exploits (for example also target arch
x86|x86_64is taken into account when generating exploits list):
$ ./linux-exploit-suggester.sh --uname "Linux taris 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux"
--pkglist-file <file>could be provided to
--unameto also check for user space exploits:
In terms of generated list of exploits its identical with executing (directly on the given remote machine):
(remote machine) $ dpkg -l > dpkgOutput.txt
$ ./linux-exploit-suggester.sh --uname "Linux taris 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux" --pkglist-file dpkgOutput.txt
Sometimes it is desired to examine only package listing (in this case only check for userspace exploits is performed):
(remote machine) $ ./linux-exploit-suggester.sh --skip-more-checks
As previously but no package versioning is performed (handy for quick preliminary checking if any package for which user space exploit is available is installed):
(remote machine) $ dpkg -l > dpkgOutput.txt
$ ./linux-exploit-suggester.sh --pkglist-file dpkgOutput.txt
Kernel version number is taken from current OS, sources for possible exploits are downloaded to current directory (only kernel space exploits are examined):
$ ./linux-exploit-suggester.sh --pkglist-file dpkgOutput.txt --skip-pkg-versions
Kernel version number is taken from command line, full details (like: kernel version requirements, comments and URL pointing to announcement/technical details about exploit) about matched exploits are listed:
$ ./linux-exploit-suggester.sh --fetch-sources --kernelspace-only
Kernel version number is taken from current OS, binaries for applicable exploits are downloaded (if available) to current directory, additional checks are skipped:
$ ./linux-exploit-suggester.sh -k 4.1 --full
Note however that
$ ./linux-exploit-suggester.sh --fetch-binaries --skip-more-checks
--fetch-binariesis not recommended as it downloads binaries from generally not trusted sources and most likely these binaries weren't compiled for your target anyway. It should be used as a kind of last resort option when you're running out of time during your pen testing engagement and there is no compiler available on your target at hand.
- The tool was inspired by the Linux_Exploit_Suggester script and it contains all the exploits that are present there (for kernels 2.6+) plus all more recent Linux kernel exploits
- It is available in BlackArch distribution
- I'm not responsible for how the tool is used and where it is used
wget https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh -O les.sh