I’ve added a few more commands/one-liners that may be of use (many of which were recently included within the latest version of LinEnum).
Well it’s been a while, but the latest (0.5 experimental) release of LinEnum is now available.
A few more scans have been added, which include password policy checks, reading of the umask setting and checking the ownership of binaries associated with inetd.conf (and variants). There will be plenty more additions in this area in the *very* near future.
However, the biggest changes have been made in the functionality of the script. The reporting functionality has been altered so it should work on legacy systems (although, admittedly ‘tee’ is a dependency). Additionally, by default, the script now runs just basic/quick checks. A ‘thorough’ tests switch (-t) has been added, which allows the user to choose if they wish to run lengthy scans (such as file permission checks, SUID/GUID file searches and so on).
The biggest addition is the introduction of ‘export’ functionality (experimental stages). If a scan is run with this switch (-e) all ‘interesting’ files (/etc/password, user history, SSH files etc.) will be copied to a location of the users choosing. Essentially these files, along with the LinEnum report (-r), should allow for easier offline analysis.
A quick peek at the help menu highlights the changes/additions:
The Github repository has been updated with this latest addition and is available from here.
If you have any suggestions/improvements/criticisms re LinEnm please do contact me and I’ll try to address these in the next release – otherwise please feel free to contribute to the project!
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.
An additional ‘extra’ feature is that the script will also use a provided keyword to search through *.conf and *.log files. Any matches will be displayed along with the full file path and line number on which the keyword was identified.
After the scan has completed (please be aware that it make take some time) you’ll be presented with (possibly quite extensive) output, to which any key findings will be highlighted in yellow with everything else documented under the relevant headings.
Example output is shown in the following screenshot:
I’m afraid from hereon in it’s a manual task to check over the results.
Below is a high-level summary of the checks/tasks performed by LinEnum:
- Kernel and distribution release details
- System Information:
- Networking details:
- Current IP
- Default route details
- DNS server information
- User Information:
- Current user details
- Last logged on users
- Llist all users including uid/gid information
- List root accounts
- 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.)
- 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/
- Display current $PATH
- List all cron jobs
- Locate all world-writable cron jobs
- Locate cron jobs owned by other users of the system
- 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):
- Default/Weak Credentials:
- Checks for default/weak Postgres accounts
- Checks for default root/root access to local MYSQL services
- 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 accesible *.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
Some of the above commands are privileged/and or the related task may be nonexistent and will therefore most likely fail. The user shouldn’t be alerted to failed results, just the output from successful commands should be displayed.
To date I’ve tested LinEnum on Ubuntu, Debian, Redhat and CentOS. If you feel that there are some additional checks that you’d like to see added to the script and/or you find any bugs etc. please post within the below comments section (or feel free to contribute towards the project).
Please note that I realise that my scripting ability is limited and there may well be better/easier/quicker ways of performing some of the tasks. However, all that said, hopefully you’ll find this a useful tool.
Finally, I’d like to say thanks to @pentestmonkey for his inspirational unix-privesc-check tool that I’ll continue to use on a very regular basis!
The following post lists a few Linux commands that may come in useful when trying to escalate privileges on a target system. This is generally aimed at enumeration rather than specific vulnerabilities/exploits and I realise these are just the tip of the iceberg in terms of what’s available.
Revision 1.1 (July 2014 update)
Kernel, Operating System & Device Information:
||Print all available system information|
||Linux kernel architecture (32 or 64 bit)|
||File system information|
Users & Groups:
||List all users on the system|
||List all groups on the system|
||List all uid’s and respective group memberships|
||Show user hashes – Privileged command|
||List all super user accounts|
||Users currently logged in|
||Who is currently logged in and what they’re doing|
||Listing of last logged on users|
||Information on when all users last logged in|
||Information on when the specified user last logged in|
||Entire list of previously logged on users|
The following post shows some possible ways to hack and gain root on VulnVPN. In these examples VulnVPN is based at 192.168.0.10 and the attacking box/client is 192.168.0.11.
Attacking the VPN Server
The first few steps involve finding the listening services. As it’s a VPN image, I’ve performed a single scan on UDP port 500 from which the result can be seen in the following screenshot.
To keep this thorough I’ve also performed a full TCP port scan although, as expected, only the open port is 81. This is used to host a help page and is out of scope for testing.
Using ike-scan it’s possible to determine that the host is running an IKE based VPN in aggressive mode, from which we can basically perform an offline attack on the hash to return the unencrypted PSK. More information on this attack can be found here.
It’s then possible to use a program such as psk-crack to perform dictionary or brute-force attacks on the hash. From the following screenshot it is evident to see that the clear text PSK value is 123456.
If you’re using the client config files supplied, you’ll need to enter the PSK into the ipsec.secrets file (as follows).
Before attempting to connect to the host you’ll need to perform a service restart i.e. /etc/init.d/ipsec restart.
It’s then possible to initiate the VPN connection using the command as shown in the following screenshot.
If the connection has been successful you’ll see ‘IPsec SA established’ message as highlighted above. If things don’t go as planned, the following may help:
- 022 “vpn”: We cannot identify ourselves with either end of this connection – This means that your IP address is not the same as specified in the ipsec.conf file. Either change your address, or change the value in the file (the default for the client is set as 192.168.0.11).
- 021 no connection named “xxxx” – The name of the connection is not as specified in ipsec.conf, i.e. vpn (the default for this challenge).
- STATE_AGGR_I1: INVALID_HASH_INFORMATION – This error indicates that the hash information in ipsec.secrets is incorrect. Ensure you enter the PSK as previously obtained.
After any changes make sure you restart the ipsec services.
This command came in very handy on a recent pentest. Essentially this allows us to dump out the SAM and SYSTEM files on a compromised host, whilst also helping avoid A/V. It should be noted that this is a post exploitation task and assumes you have SYSTEM access to the host/or are using a privileged hash to authenticate from a remote system.
If you wish to perform this attack remotely you’ll need the relevant hash and wce to perform the following command:
wce.exe -s administrator:500:LMHASH:NTHASH -c cmd.exe
Then in the spawned window you can use the following:
PsExec.exe \\%VICTIM_IP% reg save hklm\system %LOCATION% & PsExec.exe \\%VICTIM_IP% reg save hklm\sam %LOCATION%
If you have local access you can obviously drop the wce and psexec sections.
If you have any issues accessing ADMIN$ etc you can always use the reg hack as described in a previous post.
The idea behind VulnVPN is to exploit the VPN service to gain access to the sever and ‘internal’ services. Once you have an internal client address there are a number of ways of gaining root (some easier than others).
Client VPN Configuration
I have created a VulnVPN client image (x64) that has the relevant settings in place, otherwise it’s basically a standard BT5r3 image. All you’ll need to do is populate the /etc/ipsec.secrets file once you have the PSK and then restart the relevant ipsec services. The IP of the client has been set to 192.168.0.11. The username/password is the standard BT of root/toor. Alternatively you can download the client config files and use your own host, as described below.
I have created/uploaded the relevant files which can be obtained from the compressed file here. You’ll need to configure Openswan/xl2tpd on your system, if you’re using an Ubuntu based Linux variant you can follow the below steps – please note that I’ve used Backtrack 5r3 for all client testing (mentioned as I know it works well):
1. apt-get install openswan xl2tpd ppp
2. Copy the downloaded client files into the following locations:
3. VulnVPN is located at 192.168.0.10 and the client configuration files state that the client IP address is 192.168.0.11. If you want your client to have a different address ensure you change the relevant settings in /etc/ipsec.conf.
4. To establish a VPN connection run the following command: ipsec auto –up vpn (that’s two hyphens before up, they get lost in the post formatting). If you’re viewing the logs you should see something along the lines of ‘IPsec SA established’.
5. If the connection succeeds (remember you’ll need to obtain the PSK before this is possible) you can run the ‘start-vpn.sh’ script (included with client config files download) or run the following command to initialise the PPP adaptor: echo “c vpn” > /var/run/xl2tpd/l2tp-control
6. Run ip list or ifconfig and you should see that a new PPP adapter has been created and assigned an IP address (this may not be instant, give it a few seconds). If the adaptor fails to come up run the script/command again – I’ve come across this issue a few times.
Note: If you change your configuration/IP settings etc you’ll need to reload the relevant configuration files i.e. /etc/init.d/ipsec restart and/or /etc/init.d/xl2tpd restart
I realise that VPN’s can be very troublesome (setting this challenge up was bad enough), so I have allowed access to auth and ufw logs. These should help highlight issues you may be experiencing and can be found at http://192.168.0.10:81 (note port 81). Please note that hacking this page and associated scripts are not part of the challenge, rather they have been provided for assistance.
A useful config reference can also be found here:
- Architecture: x86
- Format: VMware (vmx & vmdk) compatibility with version 4 onwards
- RAM: 1GB
- Network: NAT – Static IP 192.168.0.10 (no G/W or DNS configured)
- Extracted size: 1.57GB
- Compressed (download size): 368MB – 7zip format – 7zip can be obtained from here
Download VulnVPN from -HERE-
MD5 Hash of VulnVPN.7z: 9568aa4c94bf0b5809cb0a282fffa5c2
Download Client files from -HERE-
MD5 Hash of client.7z: e598887f2e4b18cd415ea747606644f6
Download x64 Client VM Image from -HERE- (it’s big!)
MD5 Hash of client.7z: e57253a449cab4563bfa74852e1d5b2c
As per usual, I shall add a related solutions post shortly. Until then, enjoy
I was using Metasploit on an internal test (it’s been a while as I meant to write this up some time ago) and I came across the following issue when attempting to gain access to a Windows 7 system via a remote PSExec/Meterpreter session with the compromised local administrator account hash; ‘The server responded with error: STATUS_ACCESS_DENIED (Command=117)‘.
It dawned on me that the newer versions of Windows (7 and 2008) don’t allow remote access to administrative shares such as ADMIN$, C$ etc from untrusted systems. I searched a little and found the following. This should be added to the victims registry:
- Add a new DWORD (32-bit) key named ‘ LocalAccountTokenFilterPolicy’ and set the value to 1
If you don’t have access to an interactive session on the victim system, it’s possible to open a remote registry editor console using wce (Windows Credential Editor) with the following command:
wce.exe -s %local_admin_user_hash% -c cmd.exe
Essentially this command opens a cmd.exe window that’s running under the context of the chosen hash. Further, if you enter regedt32 in the spawned command window and change the target of the registry editor to the remote host, this will also authenticate on the host as the user from which cmd.exe was initially launched.
If the registry editor for the remote system is unavailable (i.e. the Remote Registry service is not running) a similar exploit can be run using wce to open an mmc. From here the computer management snap-in can be added for the remote system, again running under the context of the compromised account. The service can then be started on the remote host and you can continue to add the registry key.
After the registry settings have been added you’ll need to change the password of the user account you’re using to authenticate. Alternatively, create another local admin user via the remote computer management mmc on the remote host. Articles I’ve seen have also stated that once the changes have been made the system should be restarted. I haven’t had this issue to date and changes seem to be applied immediately.
It’s also worth noting that if you’ve previously authenticated to the system via SMB you’ll need to flush the current sessions by issuing the command net use /delete *
PSExec should then execute as planned.
Why would you want to do all of this if you already have the local administrator hash? For a number of reasons:
- AV on the system kills/deletes any malicious process/binary from spawning. Therefore wce can be used to open a remote computer management mmc in the context of the compromised account in order to disable the offending service (if the AV policies allow).
- A Meterpreter extension such as incognito (usually the reason for me) may be required so you can impersonate a user that is logged onto the system. Hence the admin shares will need to be accessible for Meterpreter to successfully spawn.
- You may want to access the administrative shares to upload/download files.
- Access to services, such as RDP or remote management facilities, may be blocked and hence attacks need to be performed over SMB.
As promised here we shall discuss a couple of ways to get root on VulnVoIP with some enumeration ‘fun’ in-between!
Assuming you’ve located the IP address, you can run a port scan and will find the following services listening (shortened for easy reference):
- 22/tcp open
- 53/tcp open domain
- 80/tcp open http
- 111/tcp open rpcbind
- 967/tcp open
- 3306/tcp open mysql
- 4445/tcp open
- 5038/tcp open asterisk
VoIP User Enumeration
In this demonstration I’m using SIPVicious to enumerate the SIP device/users and to help crack extension passwords.
The first thing to do is enumerate the end device. To do so we can use the command ./svmap.py –fingerprint 192.168.237.148
The next step is to locate valid SIP extensions. The initial command I used was ./svwar.py -D 192.168.237.148
It’s possible to specify the method used in the request. In this particular instance the INVITE request brings back valid responses ./svwar.py -D -m INVITE 192.168.237.148
If all went well you should find that 6 extensions exist. The –D option used in the previous command just searches for default extensions, so it’s generally best to use a custom range. I also found that if I specified the extensions to scan, i.e. –e100-3000, only the lower extensions were found, hence it may be best to split up long scans.
VulnVoIP is based on a relatively old AsteriskNOW distribution and has a number of weaknesses. The aim is to locate VoIP users, crack their passwords and gain access to the Support account voicemail.
Just to keep things interesting this particular disto also suffers from a known exploit from which it is relatively easy to gain a root shell. Once you’ve found the easy way, can you get root using a different method?
I’ve created these basic VoIP hacking training exercises as I found very limited resources online. Hopefully VulnVoIP will help others learn the basic fundamentals of VoIP hacking in a safe environment.
- Architecture: x86
- Format: VMware (vmx & vmdk) compatibility with version 4 onwards
- RAM: 512MB
- Network: NAT
- Extracted size: 1.68GB
- Compressed (download size): 552MB – 7zip format – 7zip can be obtained from here
- MD5 Hash of VulnVoIP.7z: 1411bc06403307d5ca2ecae47181972a
– Download VulnVoIP from HERE –
As per usual I’ll post a few tips and tricks in the write-up shortly.
Until then, enjoy!