4

I am practicing performing a pentest and getting stuck trying to get an interactive reverse shell from an internal machine to my attacker machine.

This is what I have done so far:

Me(attacker): 67.67.67.67 (some public ip)
Web app (victim): 68.68.68.68 (some public ip)
Internal Machine(web server): 10.1.1.80

Web Server info:

  • Centos
  • Apache
  • PHP
  • mysql

I found a SQL Injection vulnerability in the web application at 68.68.68.68 and using sqlmap with the --os-shell option I was able to get a Web shell through this application as the apache user. Then I executed the 'ifconfig' command which gave me an internal ip 10.1.1.80.

My goal is to get an interactive shell so I have been trying to use a reverse shell to tunnel out of the internal network to my public attacking machine. I believe the problem I am running into is the firewall.

This is what I know (using the web shell):

  • Can't view firewall rules

  • I can upload files through the web shell but I can't download or use HTTP/HTTPS directly from the internal machine through the web shell so http reverse shell would not work.

  • I also tried to run 'host google.com > /tmp/output.txt' through the web shell which gives no output leading me to believe DNS is not allowed either.

  • I have also tried my reverse shell listening on numerous popular ports which makes me think the firewall is doing deep packet inspection which is why it won't allow it to be tunneled over these ports.

  • The one thing that worked is I was able to ping my public attacker machine from the internal machine through the webshell which makes me think i could tunnel a reverse shell using ICMP. I found a tool called 'icmpsh' but unfortunately the client that runs on the victim machine is written in C for Windows only. I thought I would use 'wine' to do this on the internal linux box but can't install any programs from the internet and uploading wine through the webshell led to a lot of dependency errors. So my next plan was to write my own ICMP reverse shell in pure python but using SOCK_RAW requires sudo.

My question is do you think that ICMP is the way to tunnel a reverse shell out or is there a different protocol that I could be using or testing for? Maybe there is portable version of wine or equivalent I can upload?

PS: This is for practice so it is setup to be achievable

user0809452345
  • 93
  • 6
  • Have you scanned the LAN? You may need to move horizontally before you can get out. – TrickyDupes Oct 16 '17 at 20:17
  • @Trickycm I did see another ip on the network looking at the arp table. So yeah, maybe I do need to move horizontally first, didn't really think about that before. I'll do a scan and see what I get. Thank you – user0809452345 Oct 16 '17 at 20:23
  • Don't get hung up on the initial machine. You can get carried away with excitement sometimes when a reverse shell lands, but given this is a contrived test env the creator may well have created this box as a red herring. At the least you have a beachhead into the LAN where you can upload arbitrary tools. Upload nmap and do a proper LAN scan (if you can, this will be noisy and may trigger IDS if their is any) – TrickyDupes Oct 16 '17 at 20:26
  • @Trickycm I think you are right. Once I got that initial breach I think I got excited and got tunnel vision (no pun intended) on that one machine and wasn't really thinking it through so I definitely need to start looking at the rest of the LAN. Thank you sir – user0809452345 Oct 16 '17 at 20:30
  • I think an ICMP based reverse shell would be a really novel way to beat the challenge. You may not even have to implement fully correct ICMP headers assuming whatever firewall that they're using is just looking at headers. It might be as simple as ripping some random reverse shell off github, tacking a header on to each packet, and removing it on the other side. – Allison Oct 19 '17 at 02:46

1 Answers1

2

I have solved my issue.

TL;DR: TCP 53 was available to incoming/outgoing traffic

When checking which protocols were allowed through the firewall, I was checking DNS by using 'host google.com' and 'host -T google.com' and 'dig @8.8.8.8 google.com' and when I did not receive the expected response I assumed this meant DNS was not allowed. After coming back to the machine a couple days later I decided to setup 'nc -nvlp port#' on my attacking machine and try to connect from the victim machine using multiple ports and long behold it was able to connect via port 53. So from there I setup my payload, got my shell and then escalated privileges.

So the lesson I learn was do not rely on a results from a single tool or method. Try more than one method.

As a side thought, if anyone has some insight into why my 'dig' and 'host' commands did not work even though it would accept traffic on 53, that would be great. I guess it allowed traffic over 53 just not DNS specifically?

Thanks for the suggestions

user0809452345
  • 93
  • 6