PG - Boolean

PG – Boolean

In this walk through, we will be going through the Boolean room from Proving Grounds. This room is rated as Intermediate on the platform and it consist of exploitation bypassing of account confirmation implementations in user account creation along with the chaining of directory traversal and file upload vulnerability to get initial access. For the privilege escalation, it require abusing of irresponsible use of alias in Linux. So, let’s get started without any delay.


Machine Info:

DescriptionBoolean is an Intermediate level Linux machine that requires bypassing of account confirmation implementations in user account creation along with the chaining of directory traversal and file upload vulnerability to get initial access. For the privilege escalation, it require abusing of irresponsible use of alias in Linux.


  • I started off with my regular nmap aggressive scan and found 3 ports opened – 22 (SSH), 80 (HTTP), 33017 (Potentially HTTP).

$ sudo nmap -A
[sudo] password for wh1terose: 
Starting Nmap 7.80 ( ) at 2024-01-18 13:23 IST

Nmap scan report for
Host is up (0.20s latency).
Not shown: 997 filtered ports
22/tcp   open   ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey: 
|   2048 37:80:01:4a:43:86:30:c9:79:e7:fb:7f:3b:a4:1e:dd (RSA)
|   256 b6:18:a1:e1:98:fb:6c:c6:87:55:45:10:c6:d4:45:b9 (ECDSA)
|_  256 ab:8f:2d:e8:a2:04:e7:b7:65:d3:fe:5e:93:1e:03:67 (ED25519)
| vulners: 
|   cpe:/a:openbsd:openssh:7.9p1: 
|     	EXPLOITPACK:98FE96309F9524B8C84C508837551A19	5.8	*EXPLOIT*
|     	EDB-ID:46516	5.8	*EXPLOIT*
|     	EDB-ID:46193	5.8	*EXPLOIT*
|     	CVE-2019-6111	5.8
|     	1337DAY-ID-32328	5.8	*EXPLOIT*
|     	1337DAY-ID-32009	5.8	*EXPLOIT*
|     	PRION:CVE-2019-16905	4.4
|     	CVE-2019-16905	4.4
|     	CVE-2020-14145	4.3
|     	PRION:CVE-2019-6110	4.0
|     	PRION:CVE-2019-6109	4.0
|     	CVE-2019-6110	4.0
|     	CVE-2019-6109	4.0
|     	PRION:CVE-2019-6111	2.6
|     	PRION:CVE-2018-20685	2.6
|     	CVE-2018-20685	2.6
|_    	PACKETSTORM:151227	0.0	*EXPLOIT*
80/tcp   open   http
| fingerprint-strings: 
|   DNSStatusRequestTCP, DNSVersionBindReqTCP, GenericLines, Help, JavaRMI, Kerberos, LANDesk-RC, LDAPBindReq, LDAPSearchReq, LPDString, NCP, NotesRPC, RPCCheck, RTSPRequest, SIPOptions, SMBProgNeg, SSLSessionReq, TLSSessionReq, TerminalServer, TerminalServerCookie, WMSRequest, X11Probe, afp, giop, ms-sql-s, oracle-tns: 
|     HTTP/1.1 400 Bad Request
|   FourOhFourRequest, GetRequest, HTTPOptions: 
|     HTTP/1.0 403 Forbidden
|     Content-Type: text/html; charset=UTF-8
|_    Content-Length: 0
| http-title: Boolean
|_Requested resource was
3000/tcp closed ppp
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at :
Aggressive OS guesses: Linux 2.6.32 (88%), Linux 2.6.32 or 3.10 (88%), Linux 3.4 (88%), Linux 3.5 (88%), Linux 4.2 (88%), Linux 4.4 (88%), Synology DiskStation Manager 5.1 (88%), WatchGuard Fireware 11.8 (88%), Linux 2.6.35 (87%), Linux 3.10 (87%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 4 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 3000/tcp)
1   198.30 ms
2   197.34 ms
3   198.40 ms
4   198.53 ms

OS and Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 48.87 seconds

nmap scan

nmap scan

sudo nmap -sS -p- -T5

all TCP port scan

  • Enumerated the web server running on port 80 reveals a custom login panel. Tried bunch of common username and password combo on that but found no luck.

Boolean login panel

  • Next, tried to register as admin account on the target. However, the account creation requires confirmation for which an email has to be sent on the user’s email address.

Boolean Register User

  • Fired, gobuster on the target to reveal some hidden directories. Got one interesting one – filemanager however it required authentication.

gobuster dir -u -w ~/Desktop/Wordlist/SecLists/Discovery/Web-Content/raft-small-directories-lowercase.txt

gobuster scan

  • Checked the service running on port 33017 found a static page over there. Nothing fancy!

port 33017

Bypassing Account confirmation

  • Going back to the user account creation on port 80. I intercepted the request of account confirmation page using burpsuite where we can see the Change email parameter along with other required fields.

Burpsuite POST Request

  • Forwarded the request to server gives us a 200 OK response code with some json fields below. As per the JSON data, we got our email, user id and username there and the confirmed status as false.

Burpsuite Response

  • I manually added the user confirmation field in the POST request with user[confirmed]=true and forwarded the request to the server.

POST request with user[confirmed]=true

  • The server returned with 200 OK response again however this time our user is created.

Burpsuite POST Response

Initial Access:

  • Going back to our browser, we are now able to access the file manager.

File Manager

  • I tested if we can upload any files to the server and as per the results, we can.

New file has been uploaded

  • I clicked on the file and it uses a cwd parameter along with a file one to download the file. The cwd parameter some what looks like a “pwd” command in linux.

locating file with cwd

  • Checked the parameters for a directory traversal vulnerability and it gave me a green light by listing the server files.

.ssh directory

  • Checked for any private keys on the target using the directory traversal payloads however found nothing that we can use. However, we can still abuse this directory traversal vulnerability alongside the File upload functionality to write our public SSH keys on to the server and then use our private key to get shell access via SSH.

known_hosts file

  • Generated a pair of public and private keys using ssh-keygen. Changed the public key name to authorized_keys.

ssh-keygen -q -N '' -f sshkey
mv authorized_keys

  • Uploaded the generated public key on to the .ssh directory.

Uploading generated public keys

  • Now used the private key to get access as user remi onto the target. Captured the local flag from his home directory.

ssh -i sshkey [email protected]

local flag

Privilege Escalation:

  • Checked the alias on the target server using the below command and found an alias root that uses the root’s ssh keys to log in on the server.



  • Used the same alias to get root on to the target. Captured the root flag and completed the challenge machine.


root access

proof flag

Also Read: PG – BlackGate



So that was “Boolean” for you. We started off with a regular nmap scan and found 3 ports opened – 22 (SSH), 80 (HTTP), 33017 (Potentially HTTP). Enumerated the webserver on port 80 and found a login panel and register user functionality. Tried to create a user but got stuck at user confirmation. Then, using Burpsuite bypassed the confirmation by adding user[confirmed]=true parameter. Once bypassed, we were able to access the File manager on the server. Uploaded our public keys on the server using it and got initial access via SSH. For privilege escalation, checked the alias and found an entry for root that can be used to change user to root. Used the same and got access root. On that note, i would take your leave and will meet you in next one. Till then, “Happy hacking”.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top