SECURITY EDUCATION, PRIVACY GUIDANCE, THREAT AWARENESS, OPEN SOURCE TOOLS, RESEARCH NOTES, AND RESPONSIBLE TECHNOLOGY CONTENT

  • Penetration Testing Distribution - BackBox

    BackBox is a penetration test and security assessment oriented Ubuntu-based Linux distribution providing a network and informatic systems analysis toolkit. It includes a complete set of tools required for ethical hacking and security testing...
  • Pentest Distro Linux - Weakerth4n

    Weakerth4n is a penetration testing distribution which is built from Debian Squeeze.For the desktop environment it uses Fluxbox...
  • The Amnesic Incognito Live System - Tails

    Tails is a live system that aims to preserve your privacy and anonymity. It helps you to use the Internet anonymously and circumvent censorship...
  • Penetration Testing Distribution - BlackArch

    BlackArch is a penetration testing distribution based on Arch Linux that provides a large amount of cyber security tools. It is an open-source distro created specially for penetration testers and security researchers...
  • The Best Penetration Testing Distribution - Kali Linux

    Kali Linux is a Debian-based distribution for digital forensics and penetration testing, developed and maintained by Offensive Security. Mati Aharoni and Devon Kearns rewrote BackTrack...
  • Friendly OS designed for Pentesting - ParrotOS

    Parrot Security OS is a cloud friendly operating system designed for Pentesting, Computer Forensic, Reverse engineering, Hacking, Cloud pentesting...

Saturday, October 28, 2017

Scripted Local Linux Enumeration and Privilege Escalation Checks - LinEnum v0.6



LinEnum will automate many of the checks that I’ve documented in the Local Linux Enumeration & Privilege Escalation Cheatsheet. It’s a very basic shell script that performs over 65 checks, getting anything from kernel information to locating possible escalation points such as potentially useful SUID/GUID files and Sudo/rhost mis-configurations and more.

General usage:
version 0.6
  • Example: ./LinEnum.sh -k keyword -r report -e /tmp/ -t

OPTIONS:
  • -k Enter keyword
  • -e Enter export location
  • -t Include thorough (lengthy) tests
  • -r Enter report name
  • -h Displays this help text
Running with no options = limited scans/no output file
  • -e Requires the user enters an output location i.e. /tmp/export. If this location does not exist, it will be created.
  • -r Requires the user to enter a report name. The report (.txt file) will be saved to the current working directory.
  • -t Performs thorough (slow) tests. Without this switch default 'quick' scans are performed.
  • -k An optional switch for which the user can search for a single keyword within many files (documented below).

High-level summary of the checks/tasks performed by LinEnum:
  • Kernel and distribution release details
  • System Information:
    • Hostname
    • Networking details:
    • Current IP
    • Default route details
    • DNS server information
  • User Information:
    • Current user details
    • Last logged on users
    • Shows users logged onto the host
    • List all users including uid/gid information
    • List root accounts
    • Extracts password policies and hash storage method information
    • Checks umask value
    • Checks if password hashes are stored in /etc/passwd
    • Extract full details for ‘default’ uid’s such as 0, 1000, 1001 etc
    • Attempt to read restricted files i.e. /etc/shadow
    • List current users history files (i.e .bash_history, .nano_history etc.)
    • Basic SSH checks
  • Privileged access:
    • Determine if /etc/sudoers is accessible
    • Determine if the current user has Sudo access without a password
    • Are known ‘good’ breakout binaries available via Sudo (i.e. nmap, vim etc.)
    • Is root’s home directory accessible
    • List permissions for /home/
  • Environmental:
    • Display current $PATH
    • Displays env information
  • Jobs/Tasks:
    • List all cron jobs
    • Locate all world-writable cron jobs
    • Locate cron jobs owned by other users of the system
  • Services:
    • List network connections (TCP & UDP)
    • List running processes
    • Lookup and list process binaries and associated permissions
    • List inetd.conf/xined.conf contents and associated binary file permissions
    • List init.d binary permissions
  • Version Information (of the following):
    • Sudo
    • MYSQL
    • Postgres
    • Apache
      • Checks user config
      • Shows enabled modules
  • Default/Weak Credentials:
    • Checks for default/weak Postgres accounts
    • Checks for default/weak MYSQL accounts
  • Searches:
    • Locate all SUID/GUID files
    • Locate all world-writable SUID/GUID files
    • Locate all SUID/GUID files owned by root
    • Locate ‘interesting’ SUID/GUID files (i.e. nmap, vim etc)
    • List all world-writable files
    • Find/list all accessible *.plan files and display contents
    • Find/list all accessible *.rhosts files and display contents
    • Show NFS server details
    • Locate *.conf and *.log files containing keyword supplied at script runtime
    • List all *.conf files located in /etc
    • Locate mail
  • Platform/software specific tests:
    • Checks to determine if we're in a Docker container
    • Checks to see if the host has Docker installed

Share:

Tool to Detect Sandboxes and Analysis Environments in the Same Way as Malware Families Do - Pafish


Pafish is a demonstration tool that employs several techniques to detect sandboxes and analysis environments in the same way as malware families do.
The project is open source, you can read the code of all anti-analysis checks.

Scope
The objective of this project is to collect usual tricks seen in malware samples. This allows us to study them, and test if our analysis environments are properly implemented.

Build
Pafish is written in C and can be built with MinGW (gcc + make).
Check out "How to build" for detailed instructions.

Author
Alberto Ortega (@a0rtega - profile)

You can also download the executable of the latest stable version.

Share:

Advanced vulnerability scanning with Nmap NSE - Vulscan




Vulscan is a module which enhances nmap to a vulnerability scanner. The nmap option -sV enables version detection per service which is used to determine potential flaws according to the identified product. The data is looked up in an offline version of VulDB.

Installation
Please install the files into the following folder of your Nmap installation:
Nmap\scripts\vulscan\*

Usage
You have to run the following minimal command to initiate a simple vulnerability scan:
nmap -sV --script=vulscan/vulscan.nse www.example.com

Vulnerability Database
There are the following pre-installed databases available at the moment:

Single Database Mode
You may execute vulscan with the following argument to use a single database:
--script-args vulscandb=your_own_database
It is also possible to create and reference your own databases. This requires to create a database file, which has the following structure:
<id>;<title>
Just execute vulscan like you would by refering to one of the pre-delivered databases. Feel free to share your own database and vulnerability connection with me, to add it to the official repository.

Update Database
The vulnerability databases are updated and assembled on a regularly basis. To support the latest disclosed vulnerabilities, keep your local vulnerability databases up-to-date.
If you want to update your databases, go to the following web site and download these files:
Copy the files into your vulscan folder:
/vulscan/

Version Detection
If the version detection was able to identify the software version and the vulnerability database is providing such details, also this data is matched.
Disabling this feature might introduce false-positive but might also eliminate false-negatives and increase performance slighty. If you want to disable additional version matching, use the following argument:
--script-args vulscanversiondetection=0
Version detection of vulscan is only as good as Nmap version detection and the vulnerability database entries are. Some databases do not provide conclusive version information, which may lead to a lot of false-positives (as can be seen for Apache servers).

Match Priority
The script is trying to identify the best matches only. If no positive match could been found, the best possible match (with might be a false-positive) is put on display.
If you want to show all matches, which might introduce a lot of false-positives but might be useful for further investigation, use the following argument:
--script-args vulscanshowall=1

Interactive Mode
The interactive mode helps you to override version detection results for every port. Use the following argument to enable the interactive mode:
--script-args vulscaninteractive=1

Reporting
All matching results are printed one by line. The default layout for this is:
[{id}] {title}\n
It is possible to use another pre-defined report structure with the following argument:
--script-args vulscanoutput=details
--script-args vulscanoutput=listid
--script-args vulscanoutput=listlink
--script-args vulscanoutput=listtitle
You may enforce your own report structure by using the following argument (some examples):
--script-args vulscanoutput='{link}\n{title}\n\n'
--script-args vulscanoutput='ID: {id} - Title: {title} ({matches})\n'
--script-args vulscanoutput='{id} | {product} | {version}\n'
Supported are the following elements for a dynamic report template:
  • {id} - ID of the vulnerability
  • {title} - Title of the vulnerability
  • {matches} - Count of matches
  • {product} - Matched product string(s)
  • {version} - Matched version string(s)
  • {link} - Link to the vulnerability database entry
  • \n - Newline
  • \t - Tab
Every default database comes with an url and a link, which is used during the scanning and might be accessed as {link} within the customized report template. To use custom database links, use the following argument:
--script-args "vulscandblink=http://example.org/{id}"

Disclaimer
Keep in mind that this kind of derivative vulnerability scanning heavily relies on the confidence of the version detection of nmap, the amount of documented vulnerebilities and the accuracy of pattern matching. The existence of potential flaws is not verified with additional scanning nor exploiting techniques.



Share:
Established in 2015. Offensive Sec Blog has been sharing security research, hacking tools, threat intelligence, and offensive security content since 2015.
Copyright © OffSec Blog | Powered by OffensiveSec
Design by OffSec | Built for the security community