search

FriendZone

hashtag
Reconnaissance: NMAP

┌──(kali💀kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.10.123

21/tcp  open  ftp         vsftpd 3.0.3

22/tcp  open  ssh         OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 a9:68:24:bc:97:1f:1e:54:a5:80:45:e7:4c:d9:aa:a0 (RSA)
|   256 e5:44:01:46:ee:7a:bb:7c:e9:1a:cb:14:99:9e:2b:8e (ECDSA)
|_  256 00:4e:1a:4f:33:e8:a0:de:86:a6:e4:2a:5f:84:61:2b (ED25519)

53/tcp  open  domain      ISC BIND 9.11.3-1ubuntu1.2 (Ubuntu Linux)
| dns-nsid: 
|_  bind.version: 9.11.3-1ubuntu1.2-Ubuntu

80/tcp  open  http        Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Friend Zone Escape software

139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)

443/tcp open  ssl/http    Apache httpd 2.4.29
| tls-alpn: 
|_  http/1.1
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: 404 Not Found
| ssl-cert: Subject: commonName=friendzone.red/organizationName=CODERED/stateOrProvinceName=CODERED/countryName=JO
| Not valid before: 2018-10-05T21:02:30
|_Not valid after:  2018-11-04T21:02:30
|_ssl-date: TLS randomness does not represent time

445/tcp open  netbios-ssn Samba smbd 4.7.6-Ubuntu (workgroup: WORKGROUP)
Aggressive OS guesses: Linux 3.2 - 4.9 (96%), Linux 3.16 (95%), ASUS RT-N56U WAP (Linux 3.4) (95%), Linux 3.18 (94%), Linux 3.1 (93%), Linux 3.2 (93%), Linux 4.10 (93%), Linux 4.2 (93%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (93%), Linux 3.10 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Hosts: FRIENDZONE, 127.0.1.1; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_clock-skew: mean: -39m59s, deviation: 1h09m15s, median: -1s
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.7.6-Ubuntu)
|   Computer name: friendzone
|   NetBIOS computer name: FRIENDZONE\x00
|   Domain name: \x00
|   FQDN: friendzone
|_  System time: 2024-01-08T04:58:12+02:00
|_nbstat: NetBIOS name: FRIENDZONE, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| smb2-time: 
|   date: 2024-01-08T02:58:12
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required

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 85.15 seconds

hashtag
HTTP Port 80/tcp

I always start off with enumerating HTTP first. In this case both 80 and 443 are open so we’ll start there. We can see the email is info@friendzoneportal.red. The friendzoneportal.red could be a possible domain name. We’ll keep it in mind when enumerating DNS.

http://10.10.10.123/ info@friendzoneportal.redarrow-up-right

View the source code to see if we can find any other information. view-source:http://10.10.10.123/

Gobuster:

Nikto:

hashtag
Enumeration: HTTPS Port 443/tcp

Visiting the site over HTTPS (port 443) gives us an error.

Therefore, let’s move on to enumerating DNS.

/admin is an empty dir just like /wordpress was on http:

/js has something in it:

Going to https://friendzone.red/js/js/ gives a page:

The source reveals it also has some comments:

This doesn’t have much meaning to me yet. Might be an allusion to DNS zones. Or it might just be a troll.

hashtag
Enumeration: ISC BIND Port 53/tcp

Try to get a domain name for the IP address using nslookup. 9.11.3–1ubuntu1.2 (DNS)

We don’t get anything. However, we do have two possible domains from previous enumeration steps:

  • friendzone.red from the nmap scan, and

  • friendzoneportal.red from the HTTP website

Let’s try a zone transfer on both domains.

zone transfer command: host -l <dns_server-address>

Add all the domains/subdomains in the /hosts/etc file.

Now we start visiting the subdomains we found. Remember that we have to visit them over both HTTP and HTTPS because we’re likely to get different results.

The following sites showed us particularly interesting results.

I tried default credentials on the admin sites but that didn’t work. Before we run a password cracker on those two sites, let’s enumerate SMB. We might find credentials there.

hashtag
Enumeration: Ports 139 / Port 445/tcp: Samba smbd 4.7.6-Ubuntu

Run smbmap to list available shares and permissions.

We have READ access on the general share and READ/WRITE access on the Development share. List the content of the shares.

-R: Recursively list directories and files on all accessible shares

The Development share does not contain anything, but the general directory has a file named creds.txt! Before we download the file, let’s use smbclient to view more information about the shares.

-L: look at what services are available on a server

The extra information this gives us over smbmap is the Comment column. We can see that the files in the Files share are stored in /etc/Files on the system. Therefore, there’s a good possibility that the files stored in the Development share (which we have WRITE access to) are stored in /etc/Development. We might need this piece of information in the exploitation phase.

Let’s get the creds.txt file. First, login anonymously (without a password) into the general share.

-N: suppresses the normal password prompt from the client to the user

Download the creds.txt file from the target machine to the attack machine.

Also doesn’t work. Next, try the credentials on the

We’re in! Visit the /dashboard.php page.

It seems to be a page that allows you to view images on the site. We’ll try to gain initial access through this page.

The dashboard.php page gives us instructions on how to view an image. We need to append the following to the URL.

Final Access timestamp is 1704698027

Let’s put that timestamp number in the pagename URL parameter. After we do that we no longer get a “Final Access timestamp…” message.

During our enumeration phase, we found a URL, that allows us to upload images. Let’s try and see if the images we upload there can be viewed through the dashboard page.

When we successfully upload the image random.jpg we get a timestamp. Let’s use the image and timestamp on the dashboard page.

hashtag
Enumeration: FTP Port 21/tcp

vsftpd 3.0.3

Try the credentials on FTP.

Doesn’t work. Next, try SSH.

hashtag
Enumeration: SSH Port 22/tcp

OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)

Also doesn’t work.

hashtag
Shell as www.data

LFI Based on the recon above, there’s a likely local file include (LFI) in this page. Both parameters have potential.

Nope, it doesn’t find the image. Let’s move our focus to the pagename parameter. It seems to be running a timestamp script that generates a timestamp and outputs it on the page. Based on the way the application is currently working, my gut feeling is that it takes the filename “timestamp” and appends “.php” to it and then runs that script. Therefore, if this is vulnerable to LFI, it would be difficult to disclose sensitive files since the “.php” extension will get added to my query.

Instead, let’s try first uploading a php file and then exploiting the LFI vulnerability to output something on the page. During the enumeration phase, we found that we have READ and WRITE permissions on the Development share and that it’s likely that the files uploaded on that share are stored in the location /etc/Development (based on the Comments column).

Let’s create a simple test.php script that outputs the string “It’s working!” on the page.

Reverse Shell Cheat Sheetpentestmonkeychevron-right

Log into the Development share.

Let’s upgrade it to a better shell.

This gives us a partially interactive bash shell. To get a fully interactive shell, background the session (CTRL+ Z) and run the following in your terminal which tells your terminal to pass keyboard shortcuts to the shell.

hashtag
Priv: www-data to friend

In the /var/www/ directory, there’s folders for all the different sites, as well as an sql conf file:

Those creds happen to work for friend. I can either su friend:

SU:

SSH:

or ssh in with them:

We have rwx privileges on the /etc/Development directory as www-data. So let’s upload the LinEnum script in the Development share.

Give the script execute permissions.

I don’t seem to have execute permissions in that directory, so I’ll copy it to the tmp directory.

Navigate to the /tmp directory and try again.

That works, so the next step is to execute the script.

The results from LinEnum don’t give us anything that we could use to escalate privileges. So let’s try pspy. If you don’t have the script, you can download it from the following github repository.

LogoGitHub - DominicBreuker/pspy: Monitor linux processes without root permissionsGitHubchevron-right

Upload it and run it on the attack machine in the same way we did for LinEnum.

hashtag
Priv: friend to root

It seems that the reporter.py script is getting executed every couple of minutes as a scheduled task. Let’s view the permissions we have on that file.

We only have read permission. So let’s view the content of the file.

Here’s the soure code of the script. Most of the script is commented out so there isn’t much to do there. It does import the os module. Maybe we can hijack that. Locate the module on the machine.

Navigate to the directory and view the permissions on the file

We have rwx privileges on the os.py module! This is obviously a security misconfiguration. As a non-privileged user, I should only have read access to the script. If we add a reverse shell to the script and wait for the root owned scheduled task to run, we’ll get back a reverse shell with root privileges!

I tried accessing the os.py script using vi but the terminal was a bit screwed up. Here’s a way to fix it (courtesy of ippsec). Go to a new pane in the attack machine and enter the following command.

Even after this, vi was still a bit glitchy, so instead, I decided to download the os.py module to my attack machine using SMB, add the reverse shell there and upload it back to the target machine. Add the following reverse shell code to the bottom of the os.py file and upload it back to the target machine.

Setup a listener on the attack machine.

Wait for the scheduled task to run the reporter.py script that will in turn call the os.py module which contains our reverse shell code.

We get back a shell running with root privileges! Grab the root.txt flag.

PreviousIrkedNextSwagShop

Last updated